Browse Prior Art Database

Report Events CW, CH, CT and MultiParty to the SCP

IP.com Disclosure Number: IPCOM000028920D
Published in the IP.com Journal: Volume 4 Issue 7 (2004-07-25)
Included in the Prior Art Database: 2004-Jul-25

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

A lot of information about a call can be provided to an IN service in the Service Control Point (SCP) according to the CAMEL standard (abbreviations used in the text and in the figures see Fig. 11). Some information can be provided e.g. with the establishment of the connection to the SCP. This is e.g. information that Call Forwarding (CF), Call Hold (CH), Call Wait (CW), Call Transfer (CT), MultiParty might occur. The service may forbid e.g. MultiParty or CH or any of the pending services. To retrieve further information about future events occurring or not occurring during the call set up, the service may request a report or notification about such events. This is e.g. information about the answer event, which triggers the start of the charging for a prepaid subscriber. Some information is relevant for the service itself, some information is relevant for charging. However, it is still not possible - according to the CAMEL and ETSI-INAP standard - to pass the information about an occurring Call Hold or Call Wait to the SCP. This information is included in the charging ticket of a postpaid subscriber and may thus be charging relevant. I.e. this information may be of interest for a prepaid service.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 17% of the total text.

Page 1 of 13

S

Report Events CW, CH, CT and MultiParty to the SCP

Idea: Roland Ernst, DE-Bad Hersfeld; Hagen Scheibe, DE-Muenchen; Petra Kastl, DE-Bad Hersfeld

A lot of information about a call can be provided to an IN service in the Service Control Point (SCP) according to the CAMEL standard (abbreviations used in the text and in the figures see Fig. 11). Some information can be provided e.g. with the establishment of the connection to the SCP. This is e.g. information that Call Forwarding (CF), Call Hold (CH), Call Wait (CW), Call Transfer (CT), MultiParty might occur. The service may forbid e.g. MultiParty or CH or any of the pending services. To retrieve further information about future events occurring or not occurring during the call set up, the service may request a report or notification about such events. This is e.g. information about the answer event, which triggers the start of the charging for a prepaid subscriber. Some information is relevant for the service itself, some information is relevant for charging.

However, it is still not possible - according to the CAMEL and ETSI-INAP standard - to pass the information about an occurring Call Hold or Call Wait to the SCP. This information is included in the charging ticket of a postpaid subscriber and may thus be charging relevant. I.e. this information may be of interest for a prepaid service.

In case of Call Forwarding is occurring the SCP can only be informed if the Call Forwarding occurs in the same MSC as the IN dialogue: I.e. if for example the IN dialogue is established in the GMSC while a call forwarding due to a busy subscriber occurs in the VMSC, this CF can not be reported to the SCP. This restriction is also valid if the GMSC and the VMSC are physically one MSC. For the MultiParty and Call Transfer supplementary service it is not possible to inform the SCP using an existing IN dialogue related report or notification.

As the information about CH, CW and certain CFs is not available in the Service Control Point, it is not possible to create a service, which uses the information. It is furthermore not possible to consider the information within the prepaid service. I.e. an online charging is not possible. In consequence the services CH and CW are either not charged or the information is included in a charging ticket, which is evaluated later.

The SCP can be informed about the invocation of the supplementary services MultiParty and CT via a MAP SS-Notification message, which is not related to the IN dialogue. The SCP has to detect the related call and IN dialogue first, which is not easy, as there are of course many active IN dialogues at the same time. This is not comfortable. Furthermore, it is only possible to inform the SCP about a MultiParty or CT invocation, but not about other phases of the event like the ending of the service or the beginning of the active phase.

In the following, a different method is described. The information about an occurring CF, CH, CW, CT or Mu...