System and method for call completion on busy subscribers

[0001] The present invention generally relates to provision and support of service Call Completion on Busy Subscriber between Telephony domains and Internet domains. More specifically, the present invention relates to system and methods for supporting Call Completion on Busy Subscriber service in Internet domains inter-working with Telephony domains where said service is already supported.

[0002] There is currently a great interest world wide in providing inter-working between Telephony and Internet Protocol (IP) based networks in order to extend their respective services and advantages into the other network. One of the main reasons behind this interest resides on the higher flexibility and lower operating cost characterising the IP-based networks as transporting circuit switched network related signalling information between signalling nodes. An inter-working node acting as the border between corresponding domains, the Telephony domain and the IP domain, commonly represents such inter-working between Telephony and IP-based networks. This inter-working node is in charge of attending all the incoming requests from the IP domain as well as of sending all the traffic coming from the telephony domain to the IP domain.

[0003] One of the preferred protocols in the IP domain for call/session control is the Session Initiation Protocol (SIP), which is now under specification by the SIP Working Group of the Internet Engineering Task Forces (SIP IETF WG), within the Transport Area. In fact, several SIP entities, the so called Call Status Control Function (CSCF), have been defined in the third Generation Partnership Project (3GPP) which allow the Switched Circuit and the IP multimedia domains be interconnected.

[0004] In this respect, it is noticeable the effort in order to define protocol mapping mechanisms to make this inter-working possible between IP and Switched Circuit Networks. For example, the SIPPING Working Group within the Transport Area of the IETF defines the SIP-T framework to facilitate the interconnection of the Public Switched Telephone Network (PSTN) with the IP network. On the other hand, the Integrated Services Digital Network (ISDN) is nowadays a world wide spread network, shared by both fixed and mobile networks, wherein the ISDN User Part (ISUP) of a Signalling System 7 (SS7) is the signalling protocol that said ISDN makes use of. In this respect, the ISUP to SIP Mapping is another initiative from the SIP IETF WG, describing a way to perform the mapping between said two signalling protocols.

[0005] The current architectural proposals for this inter-working node, border between the Telephony and the IP domains, trend towards a Network Gateway (hereinafter referred to as NGW) approach, responsible for inter-working functions between Switched Circuit Networks running ISUP protocol and IP Packet Networks running SIP protocol for Call Control. Moreover, new signalling mechanisms are required in said NGW and other entities in the SIP domain to support Supplementary Services traditionally existing in the telephony domain like the aforementioned service for Call Completion on Busy Subscriber (hereinafter referred to as CCBS).

[0006] The SIP protocols or rather some of the emerging drafts in this area, like SIP Service Examples disclosed in the draft draft-ietf-sip-service-examples-03.txt, are describing how some existing ISDN/PSTN services may be extended into the SIP world. Nevertheless, there is no teaching or consideration yet in respect of how this typical telephony service, CCBS, may enter into operation as connecting Telephony and IP domains.

[0007] The CCBS supplementary service has been defined by ITU in its Recommendation Q.733.3, taking into account typical inter-working scenarios in the context of Public Networks. Said Recommendation, in this sense, is complete and stable, with all the signalling elements in place. Basically, the solution employs the Transaction Capabilities Application Part (hereinafter abbreviated as TCAP) signalling as an auxiliary transport mechanism for indications exchanged between the Originating Local Exchange in charge of the calling subscriber and the Destination Local Exchange in charge of the called subscriber. Said Originating Local Exchange (hereinafter OLE) is the exchange where the CCBS supplementary service is provided to a calling subscriber, and the Destination Local Exchange (hereinafter DLE) is the exchange serving the busy called subscriber with whom the calling subscriber is trying to talk once said called subscriber becomes idle.

[0008] In this respect, the ISUP provides also auxiliary mechanisms to indicate to the OLE and to the Calling subscriber, that a CCBS related call is possible after a first call attempt has failed due to busy conditions encountered in the DLE towards the Called subscriber. The provision also relies on the Digital subscriber Signalling System number 1 (hereinafter DSS1) protocol for those necessary indications to and from both the Calling and. Called subscribers.

[0009] In accordance with said Q.733.3 Recommendation FIG. -1a- and FIG. -1b- show the sequence of signalling events that may be carried out for invoking the CCBS service. More specifically, FIG. -1a- presents a normal call from an Originating User (OU) to a Terminating User (TU) where said TU is found to be Busy. Provided that the DLE supports the CCBS supplementary service, said DLE sets the diagnostic field of the Cause indicator parameter in the REL message to indicate whether or not CCBS is possible. For example, the DLE may answer CCBS possible to indicate its own availability for supporting CCBS services. When the OLE receives such REL message with a diagnostic field in the Cause parameter indicating CCBS possible, said OLE supporting CCBS supplementary service and said supplementary service available to the OU, the OLE starts the basic call retention procedure. However, if the DLE, the OLE or the OU do not support or do not have the service available, no particular actions are made in the network.

[0010] If the OLE receives and accepts a CCBS request from the OU as presented in FIG. -1b-, OLE sends a CCBS REQUEST invoke component in a TCAP message TC-BEGIN to the DLE and starts a CCBS request timer (T2). This invoke component comprise an indication on whether or not OLE supports the retain option. The DLE receiving said CCBS REQUEST invoke component firstly stores relevant information, then performs some compatibility checks and further returns a CCBS REQUEST response confirmation to the OLE comprising an indication on whether or not DLE supports the retain option. As returning this response confirmation, DLE starts a service duration timer (T7). The DLE is monitoring the destination TU, previously busy, for said TU becoming free. Upon receipt of the CCBS request response confirmation, the OLE firstly stops the CCBS request timer (T2) and stores relevant information, then acknowledges to the OU that the service request has been accepted and starts its own service duration timer (T3). Being the CCBS service activated, the OU can originate and receive other calls as normal.

[0011] When as a result of monitoring TU status the DLE encounters that TU is not busy, a check is performed at DLE to see whether or not there are other incoming calls waiting for such TU. Provided that there is no further incoming call, DLE starts a so-called idle guard timer (T8). When said idle guard timer (T8) expires, the CCBS request is processed. To this end, DLE reserves appropriate resources and then DLE sends towards the OLE a REMOTE USER FREE invoke component included in a TCAP TC-CONT message and starts a CCBS recall timer (T9). This recall timer, where activated, is used to preclude the handling and delivery of any Initial Address Message (IAM) other than the one expected for the CCBS service on course. Upon receipt of said REMOTE USER FREE invoke component at the OLE from the DLE, the OLE recall the OU for indicating the called subscriber is now idle to receive the call, and the CCBS recall timer (T4) is started in OLE. Provided that the OU accepts the CCBS recall before said recall timer (T4) expires at OLE, the OLE stops such timer (T4) and initiates the CCBS recall by sending an IAM message comprising a CCBS call indicator and retained call information. Moreover, said TAM also comprises an ISDN user part Preference Indicator (IPI) set to ISDN User Part required all the way. This IAM message may go through one or more Transit Exchanges (TE) until being received at the DLE. Upon receipt of said IAM at the DLE, the CCBS recall timer (T9) is stopped, and the inclusion of CCBS call indicator is checked. Provided that said indicator is included, and that resources are still reserved at DLE, the call is offered to TU with the corresponding SETUP in accordance with current protocol specification.

[0012] An interested reader can be addressed to the ITU-T Q.733.3 specifications for a more detailed explanation, including abnormal and other miscellaneous procedures CCBS related.

[0013] The solution above to implement CCBS service in classical networks has TCAP signalling as an essential feature for communication between the Originating Local Exchange (OLE) and the Destination Local Exchange (DLE) Said TCAP is in charge of managing not only the signalling required between OLE and DLE, but also managing particular operation supervision timers, and message classes in accordance with TCAP specification. However, the introduction of TCAP in IP domains, and more specifically in currently preferred protocols like the aforementioned SIP, is regarded as a quite unfeasible extension. For instance, no DSS1 capabilities exist in the SIP side either, in order to simulate such interface, and no such things as CCBS related indications exist nowadays in the SIP protocol.

[0014] At present, there is a lack of support for CCBS service in IP domains, at least in those IP domains making use of SIP signalling (hereinafter referred to as SIP domains), as inter-working with Switched Circuit domains wherein CCBS is supported. Therefore, a decision must be taken as the point in the network in which the CCBS service should be provisioned and the methods to make it use in the SIP domain. Moreover, the ambition level for the extension of the service must also be considered, that is, the CCBS service shall be provided to SCN users calling SIP subscribers as well as vice versa.

[0015] In this respect, it is a main object of the present invention to offer provision and support for CCBS service for SCN users calling to SIP subscribers as well as provision and support for CCBS service for SIP users calling to SCN subscribers. It is a further object of the present invention to accomplish the main object with fewer impacts as possible in the currently proposed system architecture wherein SCN and IP domains mutually inter-work. It is a still further object of the present invention to accomplish previous objects with fewer and backward-compatible impacts in current SIP protocol specifications.

[0016] A first embodiment of the present invention accomplishes said objects by providing a telecommunications system comprising a first SIP Domain, a second Media Domain wherein multimedia sessions are signalled by a protocol operating according to a second standard, and having means for supporting CCBS service both for subscribers of the first SIP Domain calling busy subscribers of said second Media Domain and for subscribers of said second Media Domain calling busy subscribers of the first SIP Domain.

[0017] The means in this telecommunications system include for that purpose a network node that:

[0018] handles the provision of a CCBS service for users in the first SIP Domain;

[0019] indicates to the calling user that a CCBS service is possible when the called user is busy;

[0020] monitors, at request from the calling user, the call status of the called used for detecting when the called used is idle to receive calls;

[0021] indicates to the calling user that a CCBS service may be invoked being the called user idle; and

[0022] manages the re-call from the calling user when the CCBS service is invoked towards the called user waiting for call completion.

[0023] A second embodiment of the present invention is a method, for providing a CCBS service to subscribers of a first SIP Domain receiving media calls from subscribers of a second Media Domain wherein multimedia sessions are signalled by a second protocol, comprising the steps of:

[0024] (a) finding at a network node that the called user at the SIP Domain is busy to receive new calls, and indicating to the calling user at the second Media Domain that a CCBS service is possible;

[0025] (b) monitoring from said network node the call status of the called user after the calling user having requested a CCBS service;

[0026] (c) detecting at said network node that the called user becomes idle to receive new calls, and indicating to the calling user that a CCBS service may be invoked towards the SIP Domain; and

[0027] (d) completing from said network node the re-call as invoked by the calling user towards the called user waiting for said re-call completion at the SIP Domain.

[0028] A third embodiment of the present invention is a method for providing a CCBS service to subscribers of a first SIP Domain making calls to subscribers of a second Media Domain wherein multimedia sessions are signalled by a second protocol, comprising the steps of:

[0029] (a) receiving at a network node a call from a calling user at the SIP Domain and finding at said network node that the called user at the second Media Domain is busy to receive new calls;

[0030] (b) indicating to the calling user that a CCBS service is possible at said SIP Domain;

[0031] (c) receiving at said network node a request for CCBS service from the calling user and invoking from said network node for monitoring the call status of the called user;

[0032] (d) receiving at said network node indications from the calling user at the SIP Domain about any change of call status that said calling user may suffer after having invoked the CCBS service;

[0033] (e) indicating from said network node to the calling user at the SIP Domain that a CCBS may be invoked after having detected at said network node that both calling and called user are idle to handle new calls; and

[0034] (f) receiving at said network node the re-call invoked by the calling user at the SIP Domain and completing such re-call towards the called user waiting for said re-call completion at the second Media Domain.

[0035] With regard to the nature of the second Media Domain, two basic scenarios should be considered in all the above-mentioned embodiments as included within the scope of the present invention. In a first scenario the second Media Domain is also a SIP Domain, in such a case the network node supporting the CCBS service may belong to any one of both Domains. In a second scenario, the second Media Domain is an SCN Domain and then the network node supporting the CCBS service acts as an inter-working node, namely as a gateway and, more specifically, as a Media Gateway Controller.

[0036] The features, objects and advantages of the invention will become apparent by reading this description in conjunction with the accompanying drawings, in which:

[0037] FIGS. -1a- and -1b- respectively represent the flow sequence typically followed at SCN networks for a normal call encountering the called subscriber being busy and for invocation of Call Completion on Busy Subscribers service.

[0038] FIG. 2 represents a first alternative flow sequence followed at a scenario where a calling subscriber from an SCN domain invokes a Call Completion on Busy Subscriber towards a called subscriber in a SIP domain, said first alternative flow sequence starting the called subscriber supervision within a so-called retry-after period.

[0039] FIG. 3 represents a second alternative flow sequence followed at a scenario where a calling subscriber from an SCN domain invokes a Call Completion on Busy Subscriber towards a called subscriber in a SIP domain, said second alternative flow sequence starting the called subscriber supervision within a so-called time supervision period.

[0040] FIG. 4 represents a first alternative flow sequence followed at a scenario where a calling subscriber from a SIP domain invokes a Call Completion on Busy Subscriber towards a called subscriber in an SCN domain, being said calling subscriber not involved in any new call as waiting for said called subscriber becoming idle.

[0041] FIG. 5 represents a second alternative flow sequence followed at a scenario where a calling subscriber from a SIP domain invokes a Call Completion on Busy Subscriber towards a called subscriber in an SCN domain, being said calling subscriber involved in at least a new call as waiting for said called subscriber becoming idle.

[0042] The following describes currently preferred embodiments of methods and system required to provide and support CCBS service for SCN users calling to SIP subscribers as well as for SIP users calling to SCN subscribers. For the sake of clarity, the embodiments can be better described on per calling and called subscriber domain basis, thus resulting in two basic scenarios. A first scenario where an SCN subscriber calls a busy SIP subscriber, and a second scenario where a SIP subscriber calls a busy SCN subscriber.

[0043] In accordance with a preferred embodiment for the first scenario above, the OLE in the SCN domain is the place where the CCBS service is provided in terms of subscription for SCN users calling SIP subscribers. In addition, an inter-working entity between SCN and SIP domains is required to provide, on the one hand, TCAP related capabilities and ISUP support for CCBS service towards the SCN domain and, on the other hand, SIP based protocol mechanisms towards the SIP domain. This inter-working entity is a Network Entity (NGW) or, more specifically, a Media Gateway Controller (MGC) connected to SIP User Agents (SIP-UA) in the SIP domain. Hereinafter a generic NGW is assumed for acting as inter-working entity between SCN and SIP domains in any scenario, or further embodiments, said NGW also representing the aforementioned MGC. Under this assumption, said NGW behaves as a DLE from an originating SCN perspective, that is, such NGW implements the normal and abnormal procedures in a DLE to and from the SCN domain, and carry out the new required SIP mechanisms and signalling time supervision toward the SIP domain.

[0044] In accordance with a preferred embodiment for the second scenario above, the provision of the CCBS service for SIP subscribers calling SCN subscribers requires that the generic NGW, or a more specific Media Gateway Controller, holds the CCBS service subscriptions for the SIP calling subscribers. This subscription to CCBS service may be dynamically achieved through the existing feature validation mechanisms of SIP specification. Under the assumption that a generic NGW acts as inter-working entity between SCN and SIP domains, said NGW behaves in this second scenario as an OLE from a destination SCN perspective. Said NGW implements the normal and abnormal procedures in an OLE towards the SCN domain, and carry out the new required SIP mechanisms and signalling time supervision toward the SIP domain. That is, such NGW provides, as for the first scenario, TCAP related capabilities and ISUP support for CCBS service towards the SCN domain, and SIP based protocol mechanisms towards the SIP domain.

[0045] The activation and invocation of the CCBS in the first scenario, where SCN user is calling to a busy SIP user, is presented in FIG. -2- accordingly with a currently preferred embodiment. In addition, FIG. -3- presents a quasi-replicated embodiment to the previous one in FIG. -2-, wherein a different time supervision approach is suggested for starting to monitor the called subscriber call status.

[0046] In light of the suggested signalling messages and sequences, those skilled in the art may easily appreciate possible particular variations and combinations thereof without substantially affecting essential features of the invention.

[0047] As presented in FIG. -2- and also in FIG. -3-, an Originating User (OU) in the SCN domain initiates a call (SETUP) towards a Terminating User (TU) in the SIP domain (hereinafter abbreviated as SIP-UA/TU). Said call is sent (IAM) from an Originating Local Exchange (OLE) at the SCN domain towards a generic NGW which is regarded as a Destination Local Exchange (DLE) from an SCN perspective (and thus hereinafter referred to as NGW/DLE in this scenario).

[0048] As a result of an unsuccessful call attempt, the SIP-UA/TU side explicitly indicates the ability to be supervised and to receive a CCBS call. This ability is indicated in a final response, like any of the existing results 480, 486, or 600, and better a specific one amongst them if deemed necessary, and including a new header.

[0049] This new header comprising the supervision period (Ts) desired by the called SIP-UA/TU. If the called SIP-UA/TU desires to also include a latency period (Tr1) for said supervision, said SIP-UA/TU indicates it with the retry-after header. Alternative embodiments are presented in FIG. -2- and FIG. -3- that make it use of Tr1 or Ts respectively for starting to monitor the called user call status. As following the embodiment presented in FIG. -2-, the timer Tr1 is activated as receiving it in the retry-after header. The value (Tr1) of the retry-after header should preferably not exceed 45 minutes, which is the longer time that the CCBS procedure may be typically active in the OLE (T3). In the case that the Tr1 value is exceeded, no CCBS procedure will be initiated at all. As following the embodiment shown in FIG. -3-, similar restriction applies to the supervision period indicated in the CCBS header (Ts), although a typical value of this period shall not exceed the range of 2-3 minutes. The description hereafter refers to both FIG. -2- and FIG. -3- related embodiments unless otherwise specified for particular differences.

[0050] The NGW initiates the CCBS procedure by including the CCBS possible indicator in the Diagnostic information field of the REL message. The process at the SCN side continues as for a normal CCBS service between SCN subscribers until sending a TC-BEGIN message to the NGW/DLE. The reception of said TC-BEGIN comprising a CCBS request indication is used to generate an INVITE message for alerting the called user (SIP-UA/TU) that a CCBS supervision session can be started from called user acceptance on. The acceptance of this supervision is indicated from the SIP-UA/TU to the NGW/DLE with a 200 response including the CCBS header set to CCBS supervision.

[0051] Upon receipt of said 200 response, and provided that the embodiment in FIG. -3- is followed, the supervision timer Ts is activated.

[0052] Then, irrespective of following the embodiment in FIG. -2- or the one in FIG. -3-, the NGW/DLE initiates the sending of the corresponding TC-CONT including a CCBS request response confirmation towards the SCN side, always within a T2 period set at the SCN side. Besides, the NGW/DLE also starts a CCBS service duration timer (T7).

[0053] Then, depending on the embodiment followed, upon expiration of the retry-after timer (Tr1) for embodiment in FIG. -2-, or upon expiration of supervision timer (Ts) for embodiment in FIG. -3-, the NGW/DLE initiates the supervision requests toward the called user (SIP-UA/TU).

[0054] This supervision request to be used towards the SIP called user (SIP-UA/TU) makes it use of the INFO method in SIP with a new header to indicate CCBS supervision. Successive INFO methods may be sent until receiving at the NGW/DLE a first 200 response to said INFO methods with a Called user free indication from the called user at the SIP side (SIP-UA/TU).

[0055] At this point, if a significant idle guard timer (T8) is provided at the NGW/DLE as illustrated in FIG. -3-, after expiry of said idle guard timer (T8), another supervision INFO method is issued for the last time. This idle guard timer (T8), which is particularly shown for the embodiment in FIG. -3-, could similarly be applied under the embodiment in FIG. -2- where has been omitted for the sake of clarity. Said INFO method must be answered with another 200 response with a Called user free indication to effectively continue the CCBS procedure.

[0056] Upon receipt of the applicable 200 response above, a CCBS recall timer (T9) is started in both embodiments shown in FIG. -2- and FIG. -3-. Then, a TC-CONT TCAP message including a REMOTE USER FREE invoke component is sent from the NGW/DLE towards the OLE at the SCN side, waiting for the corresponding IAM from the SCN. The OLE receiving such invoke component proceeds as in a pure SCN scenario, recalling the OU for indicating that the called user is now idle to receive the call, and starting the corresponding CCBS recall timer (T4) at the SCN side. For the sake of clarity just the normal procedure is described herein where the OU initiates the CCBS call before expiry of these recall timers and other timers.

[0057] Upon receipt of the SETUP message from the OU accepting the CCBS call the OLE stops the recall timer (T4) and initiates the CCBS recall by sending the corresponding IAM message comprising the CCBS call indicator towards the NGW/DLE.

[0058] Once the IAM is received at the NGW/DLE, the CCBS service supervision timer (T7) and the CCBS recall timer (T9) are stopped at the NGW/DLE. Then, a final re-INVITE method is issued towards the called user (SIP-UA/TU), now with the corresponding SDP information, which is the same as in the original request, and with a new header indicating CCBS recall. As shown only in FIG. -2- though also applicable for the embodiment in FIG. -3-, the called user now is able to answer the call, acknowledges are returned back to the OU, and both users are eventually connected.

[0059] The retain options typically supported at the SCN side are also applicable as inter-working with a SIP domain in accordance with the invention. Provided that a called SIP user is busy at the time of a CCBS recall, as indicated in FIG. -2- and FIG. -3- with a re-INVITE method, and assuming that the retain option is not supported, the SIP session will be closed down immediately with the BYE method. Said BYE method likely indicating CCBS supervision. Eventually, the TCAP resources are subsequently released. On the contrary, if the retain option is supported, the supervision session remains active, waiting for a new attempt from the OLE although the T7 were not restarted. On the other hand, T9 was stopped at reception of the IAM with recall indication and it would be restarted in the event of a similar message being received. In this case, no TCAP resource is released. At this point, it might also occur that a different supervision value is received in the latest 486 final answer, namely a Tr1 or a Ts. In this case, a similar process as the one respectively presented in top of FIG. -2- or FIG. -3- applies.

[0060] Generally speaking, the expiration of timers without having received the expected signalling from either the SCN side or from the SIP side is commonly driven to a sort of abnormal procedure. For example, the expiration of T9 implies the release of TCAP resources as well as the sending of a BYE method from the NGW/DLE to the SIP side to shut down the SIP session. Still another example is the deactivation of the CCBS service by the calling user. Said deactivation takes place by merely omitting the invocation of said service, being T7 expiring without having received the expected signalling. As in the preceding case, the TCAP resources are released as well as a BYE method is sent from the NGW/DLE to the SIP side terminating the SIP session. A similar behaviour is executed upon reception of TC-NOTICE TCAP message returned from the SCN as a response to the TC-CONT (Remote User Free) indication from the NGW. That is, instead of receiving an IAM message including the CCBS call, as illustrated in FIG. -2- within the time gap represented by T9, the SCN may return a TC-NOTICE with an appropriate return cause. Then, the NGW/DLE would proceed to terminate the SIP session with a BYE method instead of going ahead with the re-INVITE method. As in previous cases of any timer expiration, TCAP resources are further released. Even for a BYE method sent to the SIP side, notice that the 200 responses should preferably mirror the CCBS related header of the methods they are answering.

[0061] On the other hand, the support of the CCBS service in the aforementioned second scenario, where a SIP subscriber is calling to a busy SCN subscriber, is presented in FIG. -4- accordingly with a preferred embodiment of the present invention. In this respect, and aligned with the behaviour for previous scenario, the NGW provides TCAP capabilities as well as ISUP support for CCBS towards the called SCN side.

[0062] As presented in FIG. -4- and also in FIG. -5-, an Originating User (OU) in the SIP domain (hereinafter referred to as an OU/SIP-UA) initiates a call with a SIP INVITE method towards a Terminating User (TU) in the SCN domain. This INVITE method is received at a generic NGW that is regarded as an Originating Local Exchange from an SCN perspective (and thus hereinafter referred to as NGW/OLE in this scenario). Said call is sent (IAM) from the NGW/OLE towards the Destination Local Exchange (DLE), where the called SCN subscriber is located. The DLE at the SCN side sends a SETUP message to the Terminating User (TU) and being the subscriber busy a DISCONNECT message is returned back.

[0063] As a result of an unsuccessful call attempt, and assuming that the DLE at the SCN side supports the CCBS supplementary service, said DLE sets the diagnostic field of the Cause indicator parameter in the REL message to CCBS possible to indicate its own availability for supporting CCBS services. When the NGW/OLE receives such REL message with a diagnostic field in the Cause parameter indicating CCBS possible, said NGW/OLE checks whether or not the CCBS supplementary service is supported and available to the OU/SIP-UA. Provided that the service is supported and the calling user has provision of this service, the NGW/OLE indicates such ability in a final response, like any of the existing results 480, or 486, and better in a specific one between them if deemed necessary, and including a new header.

[0064] When this new header including the CCBS possible indicator, is received at the OU/SIP-UA, The corresponding ACK method from the SIP user shall include said CCBS header as a confirmation that CCBS supervision is requested. Once the ACK method is received at the NGW/OLE confirming the ability on the OU/SIP-UA to further invoke the CCBS service, the NGW/OLE initiates the normal retention procedures and activates the retention timer (T1). The SIP side, namely the OU/SIP-UA, must initiate a CCBS request before expiration of said retention timer (T1). To this end, an INVITE method is sent to the MGW/OLE with a CCBS supervision indication in the CCBS header and without any Session Description Protocol feature (SDP). Upon receipt of such INVITE method, the NGW/OLE generates a TC-BEGIN with a CCBS REQUEST invoke component indicating to the DLE to monitor the called user call status. An interesting notice to make at this point is that no ISDN specific parameters as, for instance, userServInf, userServInfPrime and accessTransport are necessary included in the CCBS Request invoke component of the TC-BEGIN primitive, but rather and for compatibility reasons, default values can be supplied instead. In addition, NGW/OLE firstly activates the CCBS operation timer (T2), and secondly indicates the progress of the CCBS request to the OU/SIP-UA with a provisional 100 response.

[0065] The DLE receiving said CCBS REQUEST invoke component at the SCN side firstly stores relevant information, and then starts monitoring the terminating user (TU). As receiving confirmation of the SCN called user (TU) still being busy, the DLE returns a TC-CONT TCAP message with a CCBS REQUEST response confirmation to the NGW/OLE comprising an indication on whether or not DLE supports the retain option. The DLE also activates a CCBS service duration timer (T7), and monitors the destination TU, previously busy, for said TU becoming free. Upon receipt of the CCBS request response confirmation, the NGW/OLE firstly stops the CCBS operation timer (T2) and stores relevant information. Secondly, the NGW/OLE acknowledges to the OU/SIP-UA that the service request has been accepted with a 200 response including the CCBS header set to CCBS supervision, and then activates its own service duration timer (T3). Being the CCBS service activated, the OU/SIP-UA can originate and receive other calls as normal.

[0066] In particular, the activation of the duration timer (T3) may preferably very from 15 to 45 minutes so that the supervision session must be an active session without media exchanging through. This session is of course open between the SIP user (OU/SIP-UA) and the NGW/OLE, though no switching resources are necessarily seized between said NGW/OLE and further points in the SCN domain.

[0067] At this point two different and possible situations may occur as presented in FIG. -4- and FIG. -5-. On the one hand, the calling user at the SIP side (OU/SIP-UA) may still be idle to receive and make calls, thus the OU/SIP-UA will continue on waiting for an indication of the called user (TU) becoming idle as well as presented in FIG. -4-. On the other hand, the calling user at the SIP side (OU/SIP-UA) may be encountered busy now with another call as illustrated in FIG. -5-. Provided that the OU/SIP-UA is busy upon receipt of the latest 200 response including the CCBS header set to CCBS supervision, said OU/SIP-UA sends an INFO method with a Calling user busy indication towards the NGW/OLE.

[0068] According to the sequence diagram in FIG. -5-, upon receipt of said INFO method with a Calling user busy indication, the MGW/OLE sends another TC-CONT TCAP message to the DLE including a CCBS SUSPEND invoke component. The reception of said CCBS SUSPEND invoke indication at the DLE implies the temporary interruption of monitoring the called subscriber (TU) call status. On the other hand, after having sent the CCBS SUSPEND invoke component, the NGW/OLE starts monitoring the calling user at the SIP side (OU/SIP-UA) in order to detect when said user becomes free. To this end, NGW/OLE answer the latest INFO method, which included the Calling user busy indication, with a 200 response including the CCBS header set to Calling user busy as well. When the calling user (OU/SIP-UA) becomes idle, informs the NGW/OLE about it with a new INFO method with the CCBS header set to Calling user free. Then, as receiving said indication of calling user in idle state and still being T3 period active, the NGW/OLE sends another TC-CONT TCAP message to the DLE including a CCBS RESUME invoke component. Upon receipt of said CCBS RESUME invoke indication, the DLE starts again monitoring the called subscriber (TU) call status until said called user becomes idle, as done in FIG. -4- where the calling user had been always idle during CCBS operation.

[0069] Upon receipt of an indication from the called user (TU) at the SCN side informing said called user (TU) is now idle to receive a CCBS call, a CCBS recall timer (T9) is started in the DLE under both embodiments shown in FIG. -4- and FIG. -5-. For the sake of simplicity, the idle guard timer (T8) in previous embodiments is omitted assuming no idle guard is used. Then, a TC-CONT TCAP message including a REMOTE USER FREE invoke component is sent from the DLE towards the NGW/OLE at the SIP side, waiting for the corresponding IAM from the SIP user (OU/SIP-UA). The NGW/OLE receiving such invoke component proceeds to recall the OU/SIP-UA for indicating that the called user is now idle to receive the call, and starting the corresponding CCBS recall timer (T4) at the SIP side. To this end, NGW/OLE sends an INFO method including a CCBS header set to Called user free. For the sake of clarity just the normal procedure is described herein where the OU/SIP-UA initiates the CCBS call before expiry of these recall timers and other timers.

[0070] The OU/SIP-UA acknowledges the latest INFO method with a 200 response including the same header Called user free, being able to start the CCBS recall as shown in both FIG. -4- and FIG. -5- related embodiments. Then, the calling user at the SIP side initiates the CCBS recall by issuing a re-INVITE method towards NGW/OLE, now with the corresponding SDP information and with a new header indicating CCBS recall. Upon receipt of said re-INVITE method from the OU/SIP-UA initiating the CCBS call, the MGW/OLE stops the recall timer (T4) and initiates the CCBS recall by sending the corresponding IAM message comprising the CCBS call indicator towards the DLE at the SCN side.

[0071] Once the IAM is received at the DLE, the CCBS service supervision timer (T7) and the CCBS recall timer (T9) are stopped at the DLE. Then, a final SETUP message is sent towards the called user (TU) at the SCN side. The called user (TU) now is able to answer the call, acknowledges are returned back to the OU/SIP-UA, and both users are eventually connected.

[0072] There are, nevertheless, abnormal situations with subsequent abnormal procedures that may occur under this second scenario as already explained above for the first scenario. For example, as receiving a TC-CONT message with a CCBS SUSPEND invoke component in the DLE at the SCN side as a result of a calling SIP user (OU/SIP-UA) becoming busy, said DLE might return a TC-NOTICE TCAP message from the SCN towards the NGW/OLE. That is, instead of waiting for the corresponding TC-CONT with a CCBS RESUME invoke component as illustrated in FIG. -5-, within the time gap represented by T7, the SCN side may decide to terminate the CCBS service with said TC-NOTICE including an appropriate return cause. Then, the NGW/OLE would proceed to terminate the SIP session with a BYE method towards the OU/SIP-UA including a header set to CCBS supervision. This termination must be answered from the SIP calling user (OU/SIP-UA) with a 200 response preferably including the CCBS related header, namely a CCBS supervision.

[0073] On the other hand, provided that the SIP calling user (OU/SIP-UA) decides to drop the CCBS session, the aforementioned SIP method BYE with a drop indication, and associated mechanisms at the SCN side are used to release the TC resources concerned. Still another deactivation of the service from the SIP calling user (OU/SIP-UA) may be carried out by simply omitting the service invocation within the CCBS recall timer (T4) period what generally leads to expiration of T3 as well. If any of these timer expirations occur, a TC-END with a CCBS CANCEL invoke component is sent from the NGW/OLE to the DLE at the SCN side to release TCAP resources, and a SIP BYE method is sent to the calling user (OU/SIP-UA) indicating CCBS supervision. As in previous cases, this termination must be answered from the SIP calling user (OU/SIP-UA) with a 200 response preferably including the CCBS related header, namely a CCBS supervision.