WO2010150043A1 - Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication - Google Patents

Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication Download PDF

Info

Publication number
WO2010150043A1
WO2010150043A1 PCT/IB2009/006846 IB2009006846W WO2010150043A1 WO 2010150043 A1 WO2010150043 A1 WO 2010150043A1 IB 2009006846 W IB2009006846 W IB 2009006846W WO 2010150043 A1 WO2010150043 A1 WO 2010150043A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
cscf
terminating
ccnreg
call
Prior art date
Application number
PCT/IB2009/006846
Other languages
English (en)
Inventor
Venkata Subramanian Jayaraman
Swaminathan Seetharaman
Sujatha Ananthakrishnan
Original Assignee
Alcatel Lucent
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel Lucent filed Critical Alcatel Lucent
Priority to PCT/IB2009/006846 priority Critical patent/WO2010150043A1/fr
Priority to EP09786253A priority patent/EP2446603A1/fr
Publication of WO2010150043A1 publication Critical patent/WO2010150043A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42195—Arrangements for calling back a calling subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/04—Registration at HLR or HSS [Home Subscriber Server]

Definitions

  • ISUP ISDN Integrated Service Digital Network
  • 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.
  • Examples of call completion services today include Call Completion to a Busy Subscriber (CCBS), and Call Completion on No Reply (CCNR).
  • CCBS Busy Subscriber
  • CCNR Call Completion on No Reply
  • the network elements monitor the state of the called user, and 'recalls' the calling user, when the called user becomes 'free for recall'.
  • a called user queue is used to store the relevant info, and then complete the call attempts in sequence.
  • 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.
  • 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.
  • PSTN Public Switched Telephone Network
  • PLMN Public Land Mobile Network
  • Call completion within a PLMN is available for the not-reachable case.
  • 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.
  • 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.
  • CCNReg Call Completion to a Not Registered /Not available user
  • 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:
  • 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:
  • 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
  • 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.
  • - 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.
  • 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:
  • HSS1 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.
  • HLR Home Location Register
  • AUC Authentication Centre
  • P-CSCF1 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).
  • DHCP Dynamic Host Configuration Protocol
  • PDP Public Data Protocol
  • GPRS General Packet Radio Service
  • 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.
  • S-CSCF1 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.
  • ENUM Electronic Numbering
  • I-CSCF1 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.
  • DNS Domain Name System
  • 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).
  • MRF1 Media Resource Function
  • 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 :
  • ICSCF2 An Interrogating Call Session control Function
  • PSTN Public Switched Telephone Network
  • 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.
  • ISUP ISDN User Part
  • BICC Bearer Independent Call Control
  • SIP Session Initiation Protocol
  • PCM Pulse-code modulation
  • RTP Real-Time Transport Protocol
  • SGW Signaling Gateway
  • SCTP Stream Control Transmission Protocol
  • MTP Message Transfer Part
  • SS7 Signaling System 7
  • ISUP ISDN User Part
  • MGCF Media Gateway Controller Function
  • SGW over Stream Control Transmission Protocol (SCTP). It also controls the resources in an MGW with an H.248 interface.
  • SCTP Stream Control Transmission Protocol
  • a Media Gateway 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.
  • 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.
  • 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.
  • 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.
  • CCNReg with CCBS/CCNR
  • the network monitors the registration state of the called user (User B), and will monitor when the user B is registered again.
  • 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.
  • 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).
  • 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'.
  • 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:
  • I-CSCF Proxy Call Session control Function
  • P-CSCF Proxy Call Session control Function
  • I-CSCF Interrogating Call Session control Function
  • S-CSCF1 A Serving Call Session control Function, S-CSCF1 , for User A (user equipment UE1 ).
  • S-CSCF2 A Serving Call Session control Function, S-CSCF2, for User B (user equipment UE2).
  • An application server AS1 for User A (user equipment UE1 ).
  • a Media Server which is part of a Media Resource Function, not represented, and which can play announcements.
  • - User B is 'not registered' or 'not available 1 ; - P_CSCF and LCSCF are the same for UE1 and UE2.
  • 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'.
  • the user equipment UE1 of user A sends an INVITE to the originating application server AS1, via the P-SCCF1 and S-CSCF1.
  • 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).
  • the terminating I-CSCF sends a Diameter Location-Info-Request
  • the HSS returns a DIAMETER_ERROR_IDENTITY_NOT_REGISTERED indication in a Location-Info-Answer (LIA), back to the I-CSCF.
  • LIA Location-Info-Answer
  • 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.
  • the originating application server AS1 checks if CCNReg is possible for User A, by checking if:
  • 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
  • MRF Resource Function
  • 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.
  • 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.
  • 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:
  • 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.
  • SIP Session Initiation Protocol
  • header field 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 1 can be defined. This means that the following will also be included in the SUBSCRIBE:
  • PSTN/PLMN 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).
  • 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.
  • the queue nature or, in general, the queue type
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • -- 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.
  • 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-
  • S-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.
  • SUBSCRIBE message contains the following indications: -- event: call completion;
  • HSS responds by sending a Server Assignment Answer (SAA) to the terminating S-CSCF2, with User B's profile info.
  • SAA Server Assignment Answer
  • the terminating S-CSCF2 sends the SUBSCRIBE received as described above from the I-CSCF towards the terminating application server AS2.
  • the terminating application server AS2 is required to handle the CCNReg service functions for the called user B.
  • the terminating application server AS2 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
  • 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,
  • queue-related information -- queue-nature: CCNReg.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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".
  • AS2 Application Server 2
  • AS1 Application Server 1
  • a proper NOTIFY should be sent in response to the SUBSCRIBE (after sending the appropriate 2xx response). This NOTIFY would contain:
  • a proper announcement should be played to User A (triggered by originating AS1 ) during the booking confirmation, if User B has CCNReg inhibition.
  • UE2 When User B registers, UE2 sends a REGISTER to P-CSCF, which forwards it to the I-CSCF.
  • P-CSCF will do a Domain Name System query, and forward the message to the LCSCF.
  • the I-CSCF sends a Cx query to HSS (to determine the S_CSCF).
  • 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).
  • the I-CSCF then sends a REGISTER to S-CSCF2.
  • the S-CSCF2 sends a SAR (Cx) to the HSS.
  • the HSS responds by a SAA (Cx) to the S-CSCF2.
  • 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.
  • the terminating application server AS2 sends a SUBSCRIBE (event: reg) (See Note 1 below) to S-CSCF2 .
  • the S-CSCF2 sends a 200 OK to the terminating application server AS2.
  • the S-CSCF2 sends a NOTIFY (registration status: active) to the terminating application server AS2.
  • 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.
  • the terminating application server AS2 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.
  • -- call-completion-state ready-for-call-completion.
  • -- queue-nature CCNReg.
  • S-CSCF2 and S-CSCF1 forward the NOTIFY, with the same indication, up to the originating application server AS1.
  • the originating application server AS1 answers to AS2 with 200 OK, via S-CSCF1 and S-CSCF2 .
  • 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').
  • the originating application server AS1 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.
  • CCNReg originating Node
  • 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.
  • the originating application server AS1 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).
  • 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)
  • the terminating application server AS2 forwards it towards the called user equipment UE2 (User B) via the S-CSCF2.
  • 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.
  • the terminating application server AS2 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;
  • -- 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.
  • the terminating application server AS2 sends a 180 Ringing to originating application server AS1 via S-SCCF2 and S-SCCF1.
  • 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.
  • the originating application server AS1 then initiates a Re- INVITE towards User A with the SDP offer of B, via the S-CSCF1.
  • the user equipment UE1 responds to AS1 by a message 200 OK, via S-CSCF1.
  • the application server AS1 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur un procédé de fourniture d'un service d'établissement d'appel à un utilisateur non enregistré ou non disponible (CCNReg) consistant à : envoyer (9-10) un message d'inscription SUBSCRIBE du serveur d'application initial (AS1) au I-CSCF terminal, puis envoyer (11) du I-CSCF terminal au HSS une requête d'informations de localisation (LIR), pour demander des informations concernant le S-CSCF terminal (S-CSCF2), puis envoyer (12) du HSS au I-CSCF terminal une réponse d'informations de localisation (LIA) contenant des capacités S-CSCF et/ou un nom, puis attribuer (13) un S-CSCF, appelé S-CSCF terminal (S-CSCF2) et transférer le message SUBSCRIBE audit S-CSCF terminal (S-CSCF2), puis envoyer (14) une requête d'attribution de serveur (SAR) au HSS depuis le S-CSCF2 terminal, envoyer (15) du HSS au S-CSCF terminal (S-CSCF2) une réponse d'attribution de serveur (SAA) contenant des secondes informations de profil de l'utilisateur, puis transférer (16) le message SUBSCRIBE au serveur d'application terminal (AS2), pour lui demander de gérer le service CCNReg, puis adresser (21-23) un message de notification NOTIFY avec l'indication que l'inscription de CCNReg au service CCNReg est active et que la requête CCNReg pour le premier utilisateur (User A) pour communiquer avec le second utilisateur (User B) a été mise en file d'attente.
PCT/IB2009/006846 2009-06-24 2009-06-24 Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication WO2010150043A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/IB2009/006846 WO2010150043A1 (fr) 2009-06-24 2009-06-24 Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication
EP09786253A EP2446603A1 (fr) 2009-06-24 2009-06-24 Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB2009/006846 WO2010150043A1 (fr) 2009-06-24 2009-06-24 Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication

Publications (1)

Publication Number Publication Date
WO2010150043A1 true WO2010150043A1 (fr) 2010-12-29

Family

ID=42124366

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2009/006846 WO2010150043A1 (fr) 2009-06-24 2009-06-24 Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication

Country Status (2)

Country Link
EP (1) EP2446603A1 (fr)
WO (1) WO2010150043A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2733904A1 (fr) * 2012-11-16 2014-05-21 Vodafone Group PLC Procédé, système et dispositifs de gestion de fourniture d'utilisateur d'un service dans un réseau IMS
EP2733905A1 (fr) * 2012-11-16 2014-05-21 Vodafone Group PLC Procédé, système et dispositifs de gestion d'enregistrement d'utilisateur d'un service dans un réseau IMS
GB2542592A (en) * 2015-09-24 2017-03-29 Metaswitch Networks Ltd Managing interaction constraints
CN109151221A (zh) * 2017-06-15 2019-01-04 中国移动通信集团浙江有限公司 呼叫提醒方法、提醒服务器和计算机可读存储介质
WO2019120076A1 (fr) * 2017-12-21 2019-06-27 华为技术有限公司 Procédé de communication, dispositif et système associés

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002067560A2 (fr) * 2001-02-19 2002-08-29 Siemens Aktiengesellschaft Procede de rappel automatique mis en oeuvre dans un reseau de transmission par paquets

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002067560A2 (fr) * 2001-02-19 2002-08-29 Siemens Aktiengesellschaft Procede de rappel automatique mis en oeuvre dans un reseau de transmission par paquets

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Completion of Communications to Busy Subscriber (CCBS) Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification; (Release 8)", 3GPP STANDARD; 3GPP TS 24.642, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V8.2.0, 1 June 2009 (2009-06-01), pages 1 - 41, XP050365637 *
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2 (3GPP TS 23.228 version 8.9.0 Release 8)", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, no. V8.9.0, 1 June 2009 (2009-06-01), XP014044529 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2733904A1 (fr) * 2012-11-16 2014-05-21 Vodafone Group PLC Procédé, système et dispositifs de gestion de fourniture d'utilisateur d'un service dans un réseau IMS
EP2733905A1 (fr) * 2012-11-16 2014-05-21 Vodafone Group PLC Procédé, système et dispositifs de gestion d'enregistrement d'utilisateur d'un service dans un réseau IMS
US9866434B2 (en) 2012-11-16 2018-01-09 Vodafone Ip Licensing Limited Method, system and devices for managing user registration of a service in an IMS network
GB2542592A (en) * 2015-09-24 2017-03-29 Metaswitch Networks Ltd Managing interaction constraints
US10244004B2 (en) 2015-09-24 2019-03-26 Metaswitch Networks Ltd Managing interaction constraints
GB2542592B (en) * 2015-09-24 2021-10-06 Metaswitch Networks Ltd Managing interaction constraints
CN109151221A (zh) * 2017-06-15 2019-01-04 中国移动通信集团浙江有限公司 呼叫提醒方法、提醒服务器和计算机可读存储介质
WO2019120076A1 (fr) * 2017-12-21 2019-06-27 华为技术有限公司 Procédé de communication, dispositif et système associés

Also Published As

Publication number Publication date
EP2446603A1 (fr) 2012-05-02

Similar Documents

Publication Publication Date Title
EP2243274B1 (fr) Procédé de fourniture d'un service de rappel automatique à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication
US9379914B2 (en) Method and system for implementing aggregate endpoints on IMS networks
EP2112798B1 (fr) Contrôle de service dans un système de fourniture de services
US10044553B2 (en) Media resource reservation request failure handling for voice over mobile wireless network
US20160226923A1 (en) Voice session termination for messaging clients in ims
US8953583B2 (en) Method and system for selective call forwarding based on media attributes in telecommunication network
CA2605475C (fr) Ouverture de session a partir de serveurs d'applications dans un sous-systeme multimedia ip
EP2224664A1 (fr) Procédé et système pour contrôler l'admission d'appel dans un IMS
US20100217875A1 (en) Method and apparatus for use in a communications network
JP2008543135A (ja) Ｉｐマルチメディアサブシステム（ｉｍｓ）おける呼転送
US8588791B2 (en) Method for providing IMS support for enterprise PBX users
US20110194554A1 (en) Systems and methods for implementing call pick up using gruu an ims network
WO2010150043A1 (fr) Procédé de fourniture d'un service d'exécution d'appel à un utilisateur non enregistré ou non disponible dans un réseau de télécommunication
KR100703426B1 (ko) 아이피 기반 멀티미디어 서브시스템에서 가입자 정보유실시 발신 및 착신 호를 가능하게 하는 방법 및 장치
EP2443850A1 (fr) Procédés et appareil dans un réseau de télécommunication
EP2795865B1 (fr) Établissement de session dans un réseau de sous-système multimédia ip
KR20100131787A (ko) Ｉｍｓ망의 호 처리 방법 및 장치
Subsystem–Stage All-IP Core Network Multimedia Domain
WO2009021430A1 (fr) Procédé de connexion d'appel, équipement et système dans un sous-système multimédia ip

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09786253

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2009786253

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009786253

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE