WO2010150043A1

WO2010150043A1 - A method of providing a call completion service to a not registered or not available user in a telecommunication network

Info

Publication number: WO2010150043A1
Application number: PCT/IB2009/006846
Authority: WO
Inventors: Venkata Subramanian Jayaraman; Swaminathan Seetharaman; Sujatha Ananthakrishnan
Original assignee: Alcatel Lucent
Priority date: 2009-06-24
Filing date: 2009-06-24
Publication date: 2010-12-29
Also published as: EP2446603A1

Abstract

A method is disclosed of providing a call completion service to a not registered or not available user (CCNReg): - sending (9-10) a SUBSCRIBE message, from the originating application server (AS1 ) to the terminating I-CSCF, - then sending (11 ) a Location Information Request (LIR), from the terminating I-CSCF towards the HSS, requesting information about the terminating S-CSCF (S-CSCF2), - then sending (12) a Location Info Answer (LIA) containing S-CSCF capabilities or/and name, from the HSS to the terminating I-CSCF, - then assigning (13) a S-CSCF, referred to as the terminating S- CSCF (S-CSCF2), and forwarding the SUBSCRIBE message to said the terminating S-CSCF (S-CSCF2), - then sending (14) a Server Assignment Request (SAR) from the terminating (S-CSCF2) to the HSS, - then sending (15) a Server Assignment Answer (SAA) containing second user's profile info, from the HSS to the terminating S-CSCF (S-CSCF2), - then, forwarding (16) the SUBSCRIBE message to the terminating application server (AS2), for requiring to handle the CCNReg service), - and then sending (21 -23) a NOTIFY with the indication that the CCNReg subscription to the CCNReg service is active, and that the CCNReg request for the first user (User A) to communicate with the second user (User B) has been queued.

Description

A METHOD OF PROVIDING A CALL COMPLETION SERVICE TO A NOT REGISTERED OR NOT AVAILABLE USER IN A TELECOMMUNICATION NETWORK

BACKGROUND OF THE INVENTION Acronyms

AKA Authentication and Key Agreement

AS Application Server

AVP Attribute Value Pair

CCBS Call Completion on Busy Subscriber

CCNR Call Completion on No Reply

CCNReg Call Completion Service to a user who is not registered or not available

HSS Home Subscriber Server

I-CSCF Interrogating-Call Session Control Function

IMS IP Multimedia Subsystem

IP Internet Protocol

ISUP ISDN (Integrated Service Digital Network) User

Part

LIA Location Info Answer

LIR Location Info Request

MAA Multimedia- Authentication -Answer

MAR Multimedia- Authentication -Request

MGCF Media Gateway Controller Function

MRF Media Resource Function

NGN Next Generation Network

P-CSCF Proxy-Call Session Control Function

PLMN Public Land Mobile Network

PPA Push-Profile-Answer PPR Push-Profile-Request

PS (SIP) Proxy Server

PSTN Public Switched Telephone Network

REL (ISUP) Release Message RLC (ISUP) Release Complete Message

RTA Registration Termination Answer

RTP Real-Time Transport Protocol

RTR Registration-Termination-Request

SAA Server-Assignment-Answer SAR Server-Assignment-Request

S-CSCF Serving-Call Session Control Function

SDP Session Description Protocol

SIP Session Initiation Protocol

SL Subscriber Locator

TCAP Transaction Capabilities Application Part UAA User-Authorization-Answer

UAR User-Authorization-Request

Field of the invention

The present invention generally relates to call completion services which enable call attempts to be completed by a telecom network without the calling users having to initiate (repeated) new attempts themselves. It peculiarly concerns calls which are to set up through a SIP based telecom network, in particular the IP Multimedia Subsystem.

Description of the prior art

Examples of call completion services today include Call Completion to a Busy Subscriber (CCBS), and Call Completion on No Reply (CCNR). The network elements monitor the state of the called user, and 'recalls' the calling user, when the called user becomes 'free for recall'. In case of multiple calling users making call attempts to the same called user, a called user queue is used to store the relevant info, and then complete the call attempts in sequence. (Responsibility: terminating switch). A calling user can invoke a 'call completion' service multiple times to different called users - this is also managed by using a queue for the calling user. (Responsibility: originating switch)

CCBS and CCNR are today available in the Public Switched Telephone Network (PSTN) and in the Public Land Mobile Network (PLMN), for users that are busy or that are absent when their phone terminals are called. Call completion within a PLMN, is available for the not-reachable case. With the IP based telecom networks appeared new concepts: registration and presence. In an IP based network, a user cannot be called if the user is not "registered" in a registrar server. Similarly, a user cannot benefit from presence based services, if this user has not a status "available" in a presence server.

As concerns users that are busy or absent when their phone terminals are called, CCBS and CCNR for the Next Generation Networks (NGN), and for the Internet Protocol Multimedia Subsystem (IMS) based on the Session Initiation Protocol (SIP), are being discussed in standardization bodies (ETSI TISPAN). CCBS and CCNR services for SIP-based (not necessarily IMS) networks are being discussed in IETF, and drafts have already been proposed. As concerns users that are not registered /not available, today there is no Call Completion to a Not Registered /Not available user (CCNReg) service, enabling communication attempts to a called IMS/SIP user who is not registered /not available, to be completed without the calling user having to initiate new communication attempts. Thus, there is a need to provide a method for a Completion to a Not Registered /Not available user (CCNReg) service in an IMS telecommunication network.

SUMMARY OF THE INVENTION

According to a first aspect of the present invention, there is provided a method for providing a call completion service to a not registered or not available user, this service being referred to as CCNReg, the call originating from a first user and terminating at a second user that are both in an IMS telecommunication network comprising:

- a P-CSCF,

- an originating I -CSCF, for a first user who is originating a call to a second user ,

- a terminating I-CSCF for the second user,

- an originating S-CSCF for the first user,

- a terminating S-CSCF for the second user,

- an originating application server for the first user,

- a terminating application server for the second user,

- a Home Subscriber Server;

this method comprising steps consisting in detecting that the second user is not registered or not available, and then monitoring the status of the second user ; this method comprising steps consisting in detecting that the second user is not registered or not available, and then monitoring the status of the second user, said monitoring comprising the steps of:

- sending a first SUBSCRIBE message, from the originating application server to the terminating I -CSCF, via the originating S-

CSCF, the first SUBSCRIBE message containing indications to inform the terminating I-CSCF of the initiation of the CCNReg service for completion of the communication attempt between the first user and the second user, - then, on determining that the first SUBSCRIBE message is for

CCNReg by finding the indications mentioned above, sending a Location Information Request, from the terminating I-CSCF towards the HSS, requesting information about the terminating S-CSCF ,

- then sending a Location Info Answer containing S-CSCF capabilities or/and name, from the HSS to the terminating I-CSCF,

- then, on receiving S-CSCF capabilities or/and name in the terminating I-CSCF, assigning a S-CSCF₇ referred to as the terminating S-CSCF, and forwarding the SUBSCRIBE message to said the terminating S-CSCF, - then sending a Server Assignment Request from the terminating to the HSS,

- then sending a Server Assignment Answer containing second user's profile info, from the HSS to the terminating S-CSCF ,

- then, forwarding the first SUBSCRIBE message, from the terminating S-CSCF to the terminating application server, for requiring to handle the CCNReg service functions for the second user,

- then sending a first NOTIFY message from the terminating application server to the originating application server with the indication that the CCNReg subscription to the CCNReg service is active, and that the CCNReg request for the first user to communicate with the second user has been queued,

- and when the second user becomes registered/available again, and becomes ready for completion for the CCNReg call, and the first user becomes the first entry in the call completion queue, then sending a second NOTIFY message from the terminating application server to the originating application server with the indication that the CCNReg subscription to the CCNReg service is active, and that the second user is now registered/available, i.e., ready for call completion to the first user; this method being characterized in that, for detecting that the second user is not registered or not available, it comprises the steps of:

- sending an INVITE from the user equipment (UE1 ) of the first user towards the terminating I-CSCF,

- then sending a Diameter Location Info Request from the terminating I-CSCF to the HSS, to get information about the terminating S-CSCF for the second user,

- then sending a Location-Info-Answer from the HSS to the terminating I-CSCF, this answer containing a DIAMETER_ERROR_

IDENTITY _NOT_REG ISTERED indication,

- then sending a 604 Does Not Exist Anywhere response from the terminating I-CSCF back to the originating S-CSCF which in turn forwards it to the originating application server, this response containing the indications:

- Allow-Events header: Call-completion, and, optionally,

- Reason-header: 'user not registered /user not available',

- then forwarding the SUBSCRIBE message, from the originating application server to the terminating I-CSCF, via the originating S- CSCF, this SUBSCRIBE message containing indications to inform the terminating I -CSCF of the initiation of the CCN Reg service for completion of the communication attempt between the first and the second user, - then, on determining that this SUBSCRIBE message is for CCNReg by finding the indications mentioned above, sending a Location Information Request, from the terminating I -CSCF towards the HSS, requesting information about the terminating S-CSCF, said Location Information Request containing an Attribute Value Pair to indicate to HSS that S_CSCF information should always be returned in its answer, even though the user is not registered /available, - then sending a Location Info Answer containing S-CSCF capabilities and name, from the HSS to the terminating I-CSCF.

The claimed method provides a CCNReg service because the above mentioned SUBSCRIBE-NOTIFY mechanism provides a way to monitor the status of the second user.

The invention also provides an Interrogating Call Session Control Function, a Serving Call Session Control Function, an Application Server, and a Home Subscriber Server, functionally adapted for implementing the claimed method.

Several extensions/enhancements to this method are possible, and the proposed method can be easily modified, for example, to provide: CCNReg as a terminating feature, Selective CCNReg, etc. Other features and advantages of the present invention will become more apparent from the following detailed description of implementations of the present invention, when taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

In order to illustrate in detail features and advantages of implementations of the present invention, the following will be with reference to the accompanying drawings. If possible, like or similar reference numerals designate the same or similar components throughout the figures thereof and description, in which:

- Fig. 1 represents an example of an IMS network where the method according to the invention can be applied. - Figures 2 to 12 represent the call flow in an example where the caller A and the callee B belong to a same IMS network.

DETAILED DESCRIPTION OF A PREFERRED IMPLEMENTATION

Calling user and called user belong to an IMS based network

Figure 1 represents an example of an IMS network where the method according to the invention can be implemented by executing some adapted software in the nodes.

This example of an IMS network comprises two parts, N1 and N2, which are connected together. An IMS terminal of a user A is connected to a first network part N1 which will be called originating network when the user A is calling. Network N1 comprises:

- A Home Subscriber Server, HSS1 , which is a master user database that supports the IMS network entities that actually handle calls. It contains the subscription-related information (user profiles), performs authentication and authorization of the user, and can provide information about the user's physical location. It is similar to a Home Location Register (HLR) and Authentication Centre (AUC) of a PLMN. - A Proxy Call Session control Function, P-CSCF1, which is a SIP proxy that is the first point of contact for the IMS terminal of user A. An IMS terminal discovers its P-CSCF either because it is indicated by the protocol DHCP (Dynamic Host Configuration Protocol), or because it is assigned in the PDP (Public Data Protocol) Context in the General Packet Radio Service (GPRS). A P-CSCF is assigned to an IMS terminal during registration, and does not change for the duration of the registration. The Proxy Call Session control Function P-CSCF1 sits on the path of all signaling messages to and from the terminal of user A, and can inspect every message. It authenticates the user and establishes an IPsec security association with the IMS terminal. It also generates charging records.

- A Serving Call Session control Function, S-CSCF1 , which is the central node of the signaling plane. It provides services to the users, which they subscribe to. Each terminal is associated with an S-CSCF on SIP registration. The incoming and outgoing sessions passes through it. Home Subscriber Server HSS1 maintains the information about S-CSCF1 and user's association. Home Subscriber Server HSS1 knows the users location and subscribed services. S-CSCF is typically a SIP server, but performs session control too. It uses DIAMETER Cx and Dx interfaces to the Home Subscriber Server HSS1 , for downloading and uploading user profiles - it has no local storage of the user. All necessary information is loaded from the HSS. Each terminal attached to the network part N1 is associated with S-CSCF1 on SIP registration. It handles SIP registrations, which allows it to bind the user location (e.g. the IP address of the terminal) and the SIP address of the user. It sits on the path of all signaling messages, and can inspect every message. It decides to which application server(s) a SIP message will be forwarded, in order to provide their services. It provides routing services, typically using Electronic Numbering (ENUM) lookups. It enforces the policy of the network operator. There can be multiple S-CSCF in a network, for load distribution and high availability reasons.

- An Interrogating Call Session control Function, I-CSCF1, which locates the associated S-CSCF for a user, and routes the request to it. Its IP address is published in the Domain Name System (DNS) of a domain, so that remote servers can find I-CSCF1 and use it as a forwarding point for SIP packets to this domain. The Interrogating Call Session control Function I-CSCF1 queries the Home Subscriber Server HSS1, by using the DIAMETER Cx interface to retrieve the user location, and then routes the SIP request to its assigned Serving Call Session control Function S-CSCF1. It is the Home Subscriber Server HSS1 that assigns the Serving Call Session control Function S-CSCF1 to a user, when it is queried by the Interrogating Call Session control Function I-CSCF1.

- An application server, AS1 , which hosts and executes services, and interfaces with the Serving Call Session control Function S-CSCF1 , using the protocol SIP. It can query the Home Subscriber Server HSS1.

- A Media Resource Function, MRF1 , which provides media related functions such as media manipulation (e.g. voice stream mixing) and playing of tones and announcements (Media servers). A terminal of a user B is connected to the other network part, N2, which will be called terminating network when the user B is being called. Network N2 comprises nodes, similar to the nodes of the originating network N1 :

- A Proxy-CSCF, P-CSCF2.

- A Serving-CSCF, S-CSCF2.

- An Interrogating Call Session control Function, ICSCF2.

- An application server AS2 . - A Media Resource Function MRF2. if such a SIP based network N1-N2 must be interworked with a Public Switched Telephone Network (PSTN), it further comprise PSTN Gateways. For signaling, circuit switched networks use ISDN User Part (ISUP) or Bearer Independent Call Control (BICC) over Message Transfer Part (MTP), while IMS networks use Session Initiation Protocol (SIP) over IP. For media, circuit switched networks use Pulse-code modulation (PCM), while IMS network use Real-Time Transport Protocol (RTP). The PSTN Gateways are:

- A Signaling Gateway (SGW) which interfaces with the signaling plane of the circuit switched networks. It transforms lower layer protocols, such as Stream Control Transmission Protocol (SCTP), an Internet Protocol, into Message Transfer Part (MTP), a Signaling System 7 (SS7) protocol, to pass ISDN User Part (ISUP) from the MGCF to the circuit switched network.

- A Media Gateway Controller Function (MGCF) which does call control protocol conversion between SIP and ISUP, and interfaces with the

SGW over Stream Control Transmission Protocol (SCTP). It also controls the resources in an MGW with an H.248 interface.

- A Media Gateway (MGW) interfaces with the media plane of the circuit switched network, by converting between RTP and PCM. It can also transcode when the codecs do not match (e.g. IMS might use AMR, PSTN might use G.711 ). Registration in an IMS network:

Registrations in an IMS network are performed according to the procedures described in 3GPP TS 24.228 and 3GPP TS 24.229. According to such procedures:

The UE shall register and deregister only its public user identities with the associated contact address that belong to the UE. The initial registration procedure consists of the UE sending an unprotected initial REGISTER request and, upon being challenged, sending the integrity protected REGISTER request. The UE can register a public user identity with its contact address at any time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used for SIP signaling. However, the UE shall only initiate a new registration procedure when it has received a final response from the registrar for the ongoing registration, or the previous REGISTER request has timed out.

The UE shall send only the initial REGISTER requests to the port advertised to the UE during the P-CSCF discovery procedure. If the UE does not receive any specific port information during the P-CSCF discovery procedure, the UE shall send the initial REGISTER request to the SIP default port values as specified in RFC 3261. The contents of the REGISTER message, etc. shall be in accordance with 3GPP TS 24.229.

Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations, deregistrations or registrations of additional public user identities. When the network requires authentication or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request. The actions by a UE on receiving such a response shall be in accordance with 3GPP TS 24.229. Example message flows for registration are illustrated in 3GPP TS 24.228. Typical IMS network elements involved in a REGISTER are P-CSCF, I-CSCF, HSS and in some cases an AS, with the S-CSCF usually acting as the registrar.

CCNReg Service Description

The proposed CCNReg service enables a calling user A, encountering a called user B who has not registered yet, or who has unregistered, to the network N1-N2 to have the communication completed without having to make a new communication attempt. This service can be directly used in IMS networks, in non-IMS SIP-based networks, as well as in PSTN/PLMN networks when the called user is an IMS user, and the calling user is an IMS or SIP user, or a PSTN or PLMN user.

We will describe later an interworking method which is necessary when the called party belongs to a PLMN, and the calling party is a PSTN or PLMN user, IMS or SIP user.

Though there are some similarities in this service CCNReg with CCBS/CCNR, there are several important differences in terms of the call flows, as well as the functionality required in various network elements. On activation of this CCNReg service, the network monitors the registration state of the called user (User B), and will monitor when the user B is registered again. Similarly to the CCBS/CCNR services, the network will wait a short time, after the registration of user B, for allowing the resources to be reused for user B originating a communication. If the resources are not reused within this time by User B, then the network will automatically recall user A. When user A accepts the CCNReg recall, the network will automatically generate a CCNReg call to user B. The control of the CCN Reg service is done by an application server, and it is possible for users to modify the CCNReg queue by use of appropriate procedures. The originating application server AS1 keeps track of the CCNReg requests of user A for a given period of time, up to a certain provisionable limit, and this is done by maintaining a queue for each served user. The terminating application server AS2 keeps track of the CCNReg requests directed to the user B for a given period of time, and this is done by maintaining a queue for outstanding communications towards a given user. After successful CCNReg call setup, the corresponding entry is deleted from both queues (maintained by originating and terminating application servers, AS1 and AS2 respectively).

In case of more than one endpoint for the called user B, this feature will become active only when none of them are registered. The 'not registered' case could arise when none of the called user's endpoints (terminals) are registered, or if the calling user tries to communicate with a specific endpoint (terminal) that is not registered. The approach described in this proposal can be extended to cover the latter case.

The method according to the invention, for CCNReg, can be extended for call completion based on called user 'presence'.

Detailed Description of an example of implementation of CCNReg

Figures 2 to 12 represent the call flow in an example where the caller A and the callee B belong to an IMS network. They respectively use user equipments UE1 and UE2, both connected to an example of IP based network, which comprises:

- A Proxy Call Session control Function, P-CSCF. - An Interrogating Call Session control Function, I-CSCF, common for user A and for user B (i. e. in this example, a same I-CSCF is the originating I-CSCF and the terminating I-CSCF).

- A Serving Call Session control Function, S-CSCF1 , for User A (user equipment UE1 ).

- A Serving Call Session control Function, S-CSCF2, for User B (user equipment UE2).

- An application server AS1 , for User A (user equipment UE1 ).

- An application server AS2, for User B (user equipment UE2).

- A Home subscriber Server HSS.

- A Media Server which is part of a Media Resource Function, not represented, and which can play announcements.

In this example, the assumptions are:

- User B is 'not registered' or 'not available¹; - P_CSCF and LCSCF are the same for UE1 and UE2.

CCNReg Booking

When a user (say user A of user equipment UE1 ), makes a communication attempt to a called user (User B of user equipment UE2) the network detects the registration state of the user B. We consider the case where this status is "not registered".

IMPORTANT REMARK: If there was already a S-CSCF assigned for this user B (this would happen when an S-CSCF has requested the HSS earlier to retain its identity), the user's registration state would be 'unregistered', and not 'not registered'. In this case, the HSS would return the assigned S-

CSCF2 identity to the I-CSCF1, and the incoming request (INVITE in this scenario) would then be sent to the S-CSCF2. The first and the second approaches described below are relevant only when there is no S-CSCF assigned to the user B, and the registration state of the user is 'not registered'.

On figure 2, steps:

1 -3) The user equipment UE1 of user A sends an INVITE to the originating application server AS1, via the P-SCCF1 and S-CSCF1. 4-5) The originating application server AS1 forwards the INVITE to the terminating I-CSCF via the S-CSCF1 (In this example, the same I-CSCF is also the originating I-CSCF, just for simplification in illustrating the concept, in reality it could be different, as User A and User B could belong to different IMS/SIP networks). 6) The terminating I-CSCF sends a Diameter Location-Info-Request

(LIR-Cx) to the HSS, to get the S_CSCF for UE2/User B.

On figure 3, steps:

7) The HSS returns a DIAMETER_ERROR_IDENTITY_NOT_REGISTERED indication in a Location-Info-Answer (LIA), back to the I-CSCF.

8) The terminating I-CSCF sends a 604 Does not exist Anywhere response, back to the application server AS1 of User A, via the originating S-CSCF1. The 604 Does not exist Anywhere response contains the following indications: -- Allow-Events header: Call-completion;

-- Reason-header: 'user not registered/user not available'. See Note 2 below. Note: In case of a user 'not available' (respectively user 'not present' in case of 'presence' services), appropriate values should be sent in the Reason header.

On reception of a 604 Does not exist Anywhere (Not represented on the figure), the originating application server AS1 , checks if CCNReg is possible for User A, by checking if:

- User A has subscribed to the service (and if it is activated).

- The reason header in the 604 Does not exist Anywhere response indicates 'user not registered'. See Note 2 below.

- CCNReg inhibition is not applicable (Allow-Events header contains Call Completion).

- The CCNReg queue of User A is not full.

On ensuring that the above conditions are met, the originating application server, AS1 , will start a CCNReg Retention Timer (T1 ) before the expiry of which the CCNReg booking by User A has to take place. The originating application server, AS1 , will also trigger the Media Server (in a Media

Resource Function (MRF) not represented), via the S-CSCF1 , for an announcement to be played by the Media Server to User A, informing him/her that CCNReg booking is possible, and prompting the user A to perform the booking. Subsequently the digits are collected by the MRF

(indication CCNReg booking confirmation), and sent to the originating application server AS1 (via the S-CSCF1 ). Then the originating application server AS1 initiates the status monitoring for User B: On reception of the CCNReg booking confirmation from User A, before the expiry of the CCNReg

Retention Timer T1, AS1 stops timer T1, and adds User B to the CCNReg queue of User A.

Note 1 : After confirming the CCNReg booking (both for the first approach described here, as well as the second approach described in later sections below), User A can go on-hook, i.e., terminate the current communication attempt to User B.

Note 2: The Reason header in the 604 Does not exist Anywhere response is not mandatory for a pure IMS/SIP network call (i.e., calling and called users belong to IMS/SIP networks, without involvement of any PSTN/PLMN in between), but it may be essential when interworking with PSTN/PLMN - depending on the standardization/implementation aspects.

9-10) Subsequently, the originating application server AS1 sends a SUBSCRIBE message to the terminating I-CSCF (which is the same as the originating I-CSCF in this example - just for illustration purposes) via the originating S-CSCF1. In addition, the originating application server AS1 starts a CCNReg Request operation timer T2, to supervise the subscription request of CCNReg event. This SUBSCRIBE message has the following contents:

- event: call completion;

Notes:

1. The call-completion event package is defined in the IETF Draft Extensions to the Session Initiation Protocol (SIP) for the support of the Call Completion Services for the European Telecommunications Standards Institute: draft-poetzl-bliss-call-completion-OO, available at: http^/tools.ietf.org/id/draft-poetzl-bliss-call-completion-OO.txt. 2. The following statement is taken from the IETF draft mentioned above as it is also applicable for CCNReg service: "The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/call-completion". If the header field is present, then it MUST include "application/call-completion". If the proposal as given in IETF draft-poetzl-sipping-call-completion-Ol (or later versions of it) is followed for defining queue related fields 6t operations for call completion services, then a new queue type "CCNReg¹ can be defined. This means that the following will also be included in the SUBSCRIBE:

-- queue-nature: CCNReg;

-- queue-operation: add.

Note that the SUBSCRIBE described for this approach as well as the second approach described in later sections will also contain a non-zero value in the Expires header (indicating the duration of the subscription). Since this is common to any SUBSCRIBE-NOTIFY mechanism as described in IETF RFC 3265, it may not be explicitly specified in all sections below.

GENERAL IMPORTANT REAAARKS Remark 1 :

Note that the 'queue nature' (or, in general, the queue type, providing info on the type of call completion service) info mentioned above (as well as in following sections for SUBSCRIBE and NOTIFY messages) is optional in the (initial) SUBSCRIBE message (to start the status monitoring of User B who is not registered /not available), ONLY under the following circumstances:

1. In case of calls involving only IMS/SIP networks, and separate queues are not required to be maintained in the called user's side (i.e., in the

Application Server of User B for IMS networks) for different types of call completion services (CCBS, CCNR, CCNReg, etc.).

2. In case of calls involving interworking with PSTN/PLMN, ONLY if the PSTN/PLMN is the originating network, i.e., PSTN/PLMN does not play the role of inter-connecting two IMS/SIP networks, and it is also NOT the terminating network (the called party is NOT a PLMN user). This is mainly because, for invoking different call completion services (for example CCBS, CCNR, and CCNReg now), the mapping to TCAP messages differs, so for example in case of a call from an IMS/SIP to a PLMN user, when CCNReg is invoked by the calling user, the mapping from the SIP SUBSCRIBE message to the appropriate TCAP message (and its contents) should be ensured for proper working of the call completion service. In the NOTIFY message, the queue nature (or, in general, the queue type) is optional, as it is possible to correlate the NOTIFY to the subscription that triggered this notification using the standard mechanisms as described in RFC 3265.

Remark 2 The queue operation (add, delete, suspend, resume) is optional, in the sense that it could either be used to clearly (and directly) specify the actual operation to be performed by the receiving entity (as described in draft-poetzl-sipping-call-completion-02), or if this is NOT used, such info could be "derived" by the receiving entity using other means - depending on whether it is implemented or not, the implementation logic could slightly vary, however, the basic service as such will not have any impact.

Remark 3

In any case, the presence or absence of such queue- related info (for example, queue-nature, and queue-operation), and its handling by the various network elements will not affect the basic working of the CCNReg service described here. Assuming Remark 1 is taken into account, depending on the actual standardization, and implementation, there could be some minor differences in the actual functional logic of the various involved network elements. Further, the exact fields in which the call completion service related info (described in this document) is conveyed in the SUBSCRIBE and NOTIFY messages will also not affect the basic working of the CCN Reg service described here.

Remark 4

The Reason header in the 604 Does not exist Anywhere response is not mandatory for a pure IMS/SIP network call (i.e., calling and called users belong to IMS/SIP networks, without involvement of any PSTN/PLMN in between), but it may be essential when interworking with PSTN/PLMN - depending on the standardization /implementation aspects.

Remark 5:

Aspects such as "denial-reason" and "cancellation-reason" are described based on draft-poetzl-sipping-call-completion-CG. So if this is not used as basis, then it is possible that these fields are not used at all. Hence, throughout this document, these aspects are described as "optional", as they don't have an impact on the basic functioning of the CCNReg service.

Remark 6:

It is possible that queue-state (with value request-queued (or) userfree for recall) is being used instead of the call-completion-state as described in the following sections in the NOTIFY message.

General Remark: In this section as well as in the following sections, the event-specific info, for example, call-completion-state, will be in the SIP message body, with the content type as "application/call-completion".

On figure 4, steps: 11 ) The terminating I-CSCF, on determining that this SUBSCRIBE is for CCNReg (by finding the contents mentioned above), sends a LIR request towards the HSS, requesting for S-CSCF capabilities, using a new Attribute Value Pair (AVP) in accordance with the rules laid out in 3GPP TS 29.228. A new AVP type is required in the LIR to indicate to HSS that S_CSCF info should ALWAYS be returned in the LIA (even though the user is not registered).

Note: The above AVP will be included by the I-CSCF in the LIR when the SUBSCRIBE has the following contents: -- event: Call-completion;

In addition, as stated above, optionally (see also General Important Remarks):

-- queue-nature: CCNReg; -- queue-operation: add. The new AVP will result in the HSS returning S-CSCF capabilities/ name, even when User B is not registered, and does NOT have any services active in the de-registered state.

12) The HSS responds by sending, to the I-CSCF, a Location Info Answer (LIA) containing the requested S-CSCF capabilities /name. 13) On receiving the S-CSCF capabilities / name from HSS, the I-

CSCF assigns a S-CSCF (henceforth this will be referred to as the terminating S-CSCF, S-CSCF2. Then the I-CSCF forwards the same SUBSCRIBE to the S-CSCF2. This SUBSCRIBE message contains the following indications: -- event: call completion;

In addition, as stated above, optionally (see also General Important Remarks):

-- queue-nature: CCNReg; -- queue-operation: add; for requiring the terminating application server AS2 to handle the CCNReg service functions for the second user (User B). In other words, the S-CSCF2 will check the above indications in the received SUBSCRIBE, before sending (forwarding) it to the terminating application server AS2. 14) The terminating S-CSCF2 sends a Server Assignment Request

(SAR) to HSS. This is important because when the user B (who had previously deregistered ) registers again, it is this S_CSCF which has to be used.

On figure 5, steps:

15) HSS responds by sending a Server Assignment Answer (SAA) to the terminating S-CSCF2, with User B's profile info.

16) Subsequently, the terminating S-CSCF2 sends the SUBSCRIBE received as described above from the I-CSCF towards the terminating application server AS2. Thus the terminating application server AS2 is required to handle the CCNReg service functions for the called user B.

17-20) On reception of this SUBSCRIBE, the terminating application server AS2 first responds with a 200 OK, with the subscription duration (in the Expires header) (See Note below). The message 200 OK is sent from the terminating application server AS2 to the terminating application server

AS1 via S-CSCF2, I-CSCF, S-CSCF1.

21-23) Subsequently the terminating application serverAS2 sends a NOTIFY to the originating application server AS1 , via S-CSCF2 and S-CSCF1 , with the following contents: -- Event: call-completion,

-- Subscription-State: active,

-- call-completion-state: queued

In addition, as stated earlier, optionally (see also General Important Remarks), following queue-related information: -- queue-nature: CCNReg.

Remarks: The queue-nature described in the NOTIFY message below, as well as in ALL the NOTIFY messages for the call-completion event package, is optional

In addition to what is mentioned above, if the service retention option as described in draft-poetzl-bliss-call-completion-OO (or later versions of it) (or as is currently supported in PSTN/PLMN for other call completion services such as PSTN/PLMN) is supported, then the NOTIFY message should also contain the service-retention indication.

The application server AS2, in addition also adds User A into the CCNReg queue of User B, and starts the CCNReg Service Duration timer TI (for User B) - this timer specifies the duration for which the CCNReg will be valid (i.e. User A's entry will be retained in User B's CCNReg queue, and the SUBSCRIBE-NOTIFY will be handled). On reception of the first NOTIFY from the terminating application server AS2, the originating application server AS1 stops timer T2, starts the CCNReg Duration timer for User A, T3. This timer T3 specifies the duration for which the CCNReg will be valid (i.e., User B's entry will be retained in User A's CCNReg queue, and the SUBSCRIBE-NOTIFY will be handled).

On figure 6, steps:

24-26) A message 200 OK is sent from originating application server AS1 to terminating application server AS2 via S-CSCF1, and S-CSCF2. Subsequently, a confirmation announcement is initiated by the originating application server AS1 (via the S-CSCF1 ) though the Media Resource Function MRF wherein the Media Server plays an announcement to User A that the CCNReg booking to User B, was successful. Note: In the above described first approach, since the terminating S-CSCF2 and the terminating AS2 are informed only after the CCN Reg booking confirmation by User A, in case User B has CCNReg inhibition, still User A is allowed to book the service. This is because User B's profile will be examined only by terminating S-CSCF2 and AS2. So in case User B has CCNReg inhibition, a 403 Forbidden response can be sent by Application Server 2 (AS2) to Application Server 1 (AS1 ), as this is a case of "long term denial". Alternately, a proper NOTIFY should be sent in response to the SUBSCRIBE (after sending the appropriate 2xx response). This NOTIFY would contain:

-- Subscription-State: terminated;

- Reason: rejected.

In addition, as stated earlier, optionally (see also General Important Remarks), following information:

-- queue-nature: CCNReg; (queue-related), and,

-- Denial-reason: long-term-denial.

A proper announcement should be played to User A (triggered by originating AS1 ) during the booking confirmation, if User B has CCNReg inhibition.

Note: In case of some temporary failure conditions due to which the SUBSCRIBE cannot be accepted, for example, if User B's call-completion queue is full, Application Server 2 (AS2) should send a 480 temporarily unavailable response to Application Server 1 (AS1 ). In case of some general error (for example, CCNReg inhibition as discussed above), the Application Server 2 (AS2) should send a 403 Forbidden response to Application Server 1 (AS1). Alternatively, after acknowledging the SUBSCRIBE request (with a 2xx response), a proper NOTIFY specifying that the subscription is "terminated", etc., optionally along with the appropriate "denial reason" (short-term-denial or long-term-denial) can be sent by Application Server AS2 to Application Server AS1.

A second approach will be described further, with reference to figures 17-18.

Idle Guard Timer Handling:

Later, User B registers back to the network (authentication aspects, etc. are not shown here in detail).

On figure 6, step:

27-28) When User B registers, UE2 sends a REGISTER to P-CSCF, which forwards it to the I-CSCF. The P_CSCF will do a Domain Name System query, and forward the message to the LCSCF.

29) The I-CSCF sends a Cx query to HSS (to determine the S_CSCF).

30) The HSS sends a Cx response to the LCSCF, with the name of the S_CSCF2 (which was stored in the HSS after the SUBSCRIBE was received by S_CSCF2). 31 ) The I-CSCF then sends a REGISTER to S-CSCF2.

32) The S-CSCF2 sends a SAR (Cx) to the HSS.

33) The HSS responds by a SAA (Cx) to the S-CSCF2.

On figure 7, steps: 34) The S-CSCF2 sends a (Third party) REGISTER to the terminating application server AS2.

35) The terminating application server AS2 responds by sending a 200 OK. 36-38) S-CSCF2 forwards this 200 OK to UE2, via 1-CSCF, and P- CSCF.

39) The terminating application server AS2 sends a SUBSCRIBE (event: reg) (See Note 1 below) to S-CSCF2 . 40) The S-CSCF2 sends a 200 OK to the terminating application server AS2.

41 ) Then the S-CSCF2 sends a NOTIFY (registration status: active) to the terminating application server AS2.

42) The terminating application server AS2 answers to S-CSCF2 by a 200 OK. So the terminating application server AS2 has been informed of the registration event via the S-CSCF2 (See Note 1 below). If there is any CCNReg queue entry pending for User B, the terminating application server AS2 starts a destination idle guard timer T8, during which User B will be able to initiate communication attempts. During this period, all incoming calls will encounter the 'busy' indication (See Notes 2 and 3 below). The idle guard timer T8 may optionally be started by AS2 when User B registers back into the network. Only on expiry of idle guard timer (and User B is free), the NOTIFY will be sent to the Originating AS that User B is free for Recall. The actions associated with idle guard timer are not illustrated here.

On figure 8, steps:

43) On expiry of timer T8 (and User B is free), the terminating application server AS2 sends a NOTIFY (see Note 4 below) to S-CSCF2 with the following indications. It also starts a Timer T9 for recalling CCNReg Destination Node.

-- Event = call-completion;

-- Subscription-State: active;

-- call-completion-state : ready-for-call-completion. In addition, as stated earlier, optionally (see also General Important Remarks), following queue-related information: -- queue-nature: CCNReg.

Note: The NOTIFY message described above with the indication "ready-for- call-completion" is sent to the first entry in User B's queue. Here, as well as in sections below, it is assumed that User A is the first entry in User B's queue.

44-45) S-CSCF2 and S-CSCF1 forward the NOTIFY, with the same indication, up to the originating application server AS1.

46-48) The originating application server AS1 answers to AS2 with 200 OK, via S-CSCF1 and S-CSCF2 .

Note 1 : The S-CSCF2 on receiving a REGISTER, would initiate a third party REGISTER towards the (terminating) AS2 (that is already assigned for User B). The terminating AS2 could subscribe to the 'reg' event package, when it receives a third party REGISTER request: the basic mechanism is described in IETF RFC 3680 and 3GPP TS 24.229 (Section 'Common Application Server (AS) Procedures').

Note 2: Of course, a variant of this could be that User B is also allowed to receive incoming calls (if user B is free) during the idle guard period (i.e., the idle guard timer can be a configurable value by the operator). Note 3: This 'busy' indication could result in interaction with CCBS service.

Note 4: The NOTIFY mentioned above is sent to the first (active) entry in the CCNReg queue of User B. CCNReg Recall to User A:

Since User B is free for recall, AS1 initiates the CCNReg call completion procedures.

On figure 8, step:

49) After receiving information that User B has registered/is now available, by the indication 'ready-for-call-completion' (via a NOTIFY message), the originating application server AS1 recalls User A by sending an INVITE (without SDP) to the S-CSCF1. The originating application server AS1 will also start the CCNReg (originating Node) Recall Timer T4 within which the User A has to reply to the INVITE.

On figure 9, step:

50) The S-CSCF1 forwards the INVITE to UE1. 51 -52) When User A accepts the Recall, by picking up the phone,

UE 1 sends a 200 OK to the application server AS1 , via S-CSCF1. User B will now be recalled. On reception of 200 OK (with SDP Offer) from User A, the originating application server AS1 initiates an announcement which indicates to user A that the CCNReg call is being completed, and the call to User B is being connected. This announcement is triggered by contacting the Media Resource Function via the S-CSCF1 (Step not represented).

CCNReg Call to User B On figure 9, step: 53-55) After completion of the announcement playing to User A

(that the CCNReg call is being completed), the originating application server AS1 sends an INVITE (without SDP) to the terminating application server AS2, via the S-CSCF1 and S-CSCF2, with the P-Service-lndication header containing the value 'cess'. 56-57) On reception of this INVITE, the terminating application server AS2 forwards it towards the called user equipment UE2 (User B) via the S-CSCF2.

Note: In some call scenarios, it is possible that, say, a 183 Session Progress or 200 OK response is sent instead of 180 Ringing. In these cases also, the subscription termination operations explained below will be initiated by the terminating AS after sending the 183 Session Progress or 200 OK response.

58-59) UE2 responds with a 180 Ringing message to the terminating application server AS2, via S-CSCF2. Subsequently, on reception of 180 Ringing, from UE2, the terminating application server AS2 cancels timers T9 and 17, and releases the resources associated with this CCNReg request, including the corresponding queue entry.

On figure 10, steps:

60-62) On reception of the 180 Ringing from UE2 (via S-CSCF2), the terminating application server AS2 terminates the subscription request for monitoring the registered status of User B. This is accomplished by sending a NOTIFY, with the following contents, towards originating application server AS1 , via the S-CSCF1 and S-CSCF2, and by clearing the corresponding queue entries and timers. - Event: call-completion; -- Subscription-State: terminated;

-- reason: no resource.

In addition, as stated earlier, optionally (see also General Important Remarks), following information: -- queue-nature: CCNReg; (which is queue related), and -- cancellation-reason: service-completed.

The originating application server AS1 on reception of this (successful) subscription cancellation, stops timer T3 and sends 200 OK (not represented) to the terminating application server AS2.

63-65) The terminating application server AS2 sends a 180 Ringing to originating application server AS1 via S-SCCF2 and S-SCCF1.

On figure 11 , step: 66-67) Later, when User B goes off-hook and accepts the call, a 200

OK (with SDP) is sent towards the terminating application server AS2 via the S-CSCF2. This is then passed on towards the originating application server AS1.

68-70) The terminating application server AS2 forwards this 200 OK to the originating application server AS1 via S-SCCF2 and S-SCCF1. 71 -73) UE1 sends a 200 OK to AS1 via S-SCCF1.

On figure 12, steps:

74-75) The originating application server AS1 then initiates a Re- INVITE towards User A with the SDP offer of B, via the S-CSCF1.

76-77) The user equipment UE1 responds to AS1 by a message 200 OK, via S-CSCF1.

78-79) After receiving 200 OK from User A, the application server AS1 sends a message ACK directly to UE1 , and sends a message ACK (with SDP of A) directly to UE2 without involving the terminating application server AS2. A RTP path is established between UE1 and UE2. Subsequently (Step not represented) the originating application server AS1 also releases the call towards the MRF (that was established to play the CCNReg call connection announcement to User A). With this, the call completion actions are finished, and further steps will be similar to a normal call scenario.

Claims

THERE IS CLAIMED:

1 ) A method of providing a call completion service to a not registered or not available user, this service being referred to as CCNReg, the call originating from a first user and terminating at a second user that are both in an IMS telecommunication network comprising:

- a P-CSCF,

- an originating I -CSCF (I -CSCF), for a first user (User A) who is originating a call to a second user (User B),

- a terminating I-CSCF (I-CSCF), for the second user (User B),

- an originating S-CSCF (S-CSCF1 ), for the first user (User A),

- a terminating S-CSCF (S-CSCF2), for the second user (User B),

- an originating application server (AS1 ), for the first user (User A),

- a terminating application server (AS2), for the second user (User B),

- a Home Subscriber Server (HSS); this method comprising steps consisting in detecting that the second user (user B) is not registered or not available, and then monitoring the status of the second user, said monitoring comprising the steps of: - sending (9-10) a SUBSCRIBE message, from the originating application server (AS1) to the terminating I-CSCF, via the originating S-CSCF (S-CSCF1), said SUBSCRIBE message containing indications to inform the terminating I-CSCF of the initiation of the CCNReg service for completion of the communication attempt between the first user and the second user, - then, on determining that said SUBSCRIBE message is for CCNReg by finding the indications mentioned above, sending (11) a Location Information Request (LIR), from the terminating I-CSCF towards the HSS, requesting information about the terminating S-CSCF (S- CSCF2),

- then sending (12) a Location Info Answer (LIA) containing S-CSCF capabilities or/and name, from the HSS to the terminating I-CSCF,

- then, on receiving S-CSCF capabilities or/and name in the terminating I-CSCF, assigning (13) a S-CSCF, referred to as the terminating S-CSCF (S-CSCF2), and forwarding said SUBSCRIBE message to said the terminating S-CSCF (S-CSCF2),

- then sending (14) a Server Assignment Request (SAR) from the terminating (S-CSCF2) to the HSS,

- then sending (15) a Server Assignment Answer (SAA) containing second user's profile info, from the HSS to the terminating S-CSCF

(S-CSCF2),

- then, forwarding (16) said SUBSCRIBE message, from the terminating S-CSCF (S-CSCF2) to the terminating application server (AS2), for requiring to handle the CCNReg service functions for the second user (User B),

- and then sending (21 -23) a first NOTIFY message from the terminating application server (AS2) to the originating application server (AS1 ) with the indication that the CCNReg subscription to the CCNReg service is active, and that the CCNReg request for the first user (User A) to communicate with the second user (User B) has been queued;

- and when the second user (User B) becomes registered/available again, and becomes ready for completion for the CCNReg call, and the first user (User A) becomes the first entry in the call completion queue, then sending (43-45) a second NOTIFY message from the terminating application server (AS2) to the originating application server (AS1 ) with the indication that the CCNReg subscription to the CCNReg service is active, and that the second user (User B) is now registered/available, i.e., ready for call completion to the first user (User A).; this method being characterized in that, for detecting that the second user (user B) is not registered or not available, it comprises the steps of:

- sending (1 -5) an INVITE from the user equipment (UE1 ) of the first user towards the terminating I-CSCF,

- then sending (6) a Diameter Location Info Request (LIR-Cx) from the terminating I-CSCF (I-CSCF) to the HSS, to get information about the terminating S-CSCF for the second user,

- then sending (7) a Location-Info-Answer (LIA) from the HSS to the terminating I-CSCF, this answer containing a DIAMETERJΞRROR_

IDENTITY _NOT_REG ISTERED indication,

- then sending (8) a 604 Does Not Exist Anywhere response from the terminating I-CSCF back to the originating S-CSCF (S-CSCF1 ) which in turn forwards it to the originating application server (AS1 ), this response containing the indications:

-- AUow-Events header: Call-completion, and, optionally, -- Reason-header: 'user not registered /user not available'.

- then forwarding (9-10) the SUBSCRIBE message, from the originating application server (AS1 ) to the terminating I-CSCF, via the originating S-CSCF (S-CSCF1 ), this SUBSCRIBE message containing indications to inform the terminating I-CSCF of the initiation of the CCNReg service for completion of the communication attempt between the first and the second user, - then, on determining that this SUBSCRIBE message is for CCNReg by finding the indications mentioned above, sending (11 ) a Location Information Request (LIR), from the terminating I-CSCF towards the HSS, requesting information about the terminating S-CSCF, said Location Information Request containing an Attribute Value Pair to indicate to HSS that S_CSCF information should always be returned in its answer, even though the user is not registered /available,

- then sending (12) a Location Info Answer containing S-CSCF capabilities and name, from the HSS to the terminating I-CSCF.

2) Method according to claim 1 , wherein said SUBSCRIBE message contains the following indications:

-- event: call completion.

3) Method according to 2, wherein said SUBSCRIBE message further contains the following indications:

- queue-nature: CCNReg, -- queue-operation: add.

4) Method according to claim 1 , wherein said first NOTIFY message contains:

-- event: call completion, -- call-completion-state: queued

5) Method according to claim 1 , wherein said first NOTIFY message further contains :

-- queue-state: "request-queued", -- queue-nature: CCNReg. 6) Method according to claim 1 , wherein said second NOTIFY message contains :

-- event: call completion,

-- call-completion-state: ready-for-call-completion. 7) Method according to claim 1 , wherein said second NOTIFY message further contains :

- queue-state: "user-free-for-recall",

-- queue-nature: CCNReg.

8) Interrogating Call Session Control Function, characterized in that it comprises means functionally adapted for implementing the claimed method according to one the claims 1 to 7.

9) Serving Call Session Control Function, characterized in that it comprises means functionally adapted for implementing the claimed method according to one the claims 1 to 7.

10) Application Server, characterized in that it comprises means functionally adapted for implementing the claimed method according to one the claims 1 to 7.

11 ) Home Subscriber Server, characterized in that it comprises means functionally adapted for implementing the claimed method according to one the claims 1 to 7.