WO2012056262A1

WO2012056262A1 - Mechanism to convey dynamic charging information over ims networks

Info

Publication number: WO2012056262A1
Application number: PCT/IB2010/003032
Authority: WO
Inventors: Seetharaman Swaminathan; Kuldeep Singh
Original assignee: Alcatel Lucent
Priority date: 2010-10-25
Filing date: 2010-10-25
Publication date: 2012-05-03

Abstract

A system and method for charging users for a communication session in IMS networks. A first user or the second user informs the network to charge a third user for the communication session between the first user and a second user. The first user or the second user requests for session cost related information from the IMS network and obtains the session cost related information from the IMS network. The first user and the second user communicate with each other and the network charges the third user for the communication session. The first user or the second user informs the network to charge a third user for the communication session using charging information in Session Initiation Protocol (SIP).

Description

Mechanism to convey dynamic charging information over IMS Networks

TECHNICAL FIELD

[001] The present invention relates to communication networks and, more particularly, to charging of communication sessions in communication networks.

BACKGROUND

[002] Internet Protocol Multimedia Subsystems (IMS) provide multimedia services over third generation (3G) mobile communication systems. IMS facilitates communication between person-to-person and person-to-content over IP based communication networks. IMS uses Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals. Media components of the session are described by the session description protocol (SDP).

[003] Dynamic Charging Platforms (DCP) enables real-time, value based charging of advanced network services such as content, mobile commerce and so on. DCP bi-directionally connects and integrates, in real time, the network gateways, probes and servers that generate event information with the authentication, balance management and billing systems. This facilitates instant, two way communications between network elements, pricing engines and customer billing systems along with reliable post event processing to ensure payment and service quality.

[004] Other means for conveying charging related information for the sessions include P- charging vector and P-charging info. The P-charge info is a private SIP header which provides simple billing information for a particular call. The charge related information is typically inserted by the SIP proxy on the originating network. The information can also be inserted by the Public Switched Telephone Network (PSTN) gateways acting as a SIP User Agent (UA). The charging related information is transmitted only in one direction and the P-charge info header does not consider various likely scenarios. For example, current systems do not allow a condition wherein the calling user does not wish to be charged for some of the media types involved in the call/session and the called user also does not wish to be charged for those media types. Also, if any of the users wish to know the cost related information for a communication session before starting the session, then there is no means by which a user can know the session cost related information. For example, if a user wishes to know the pulse rate for the session before the charging for the session commences, there is no way to know it before the session using current systems.

SUMMARY

[005] In view of the foregoing, an embodiment herein provides a method for charging users for a communication session in IMS/SIP networks. A first user or the second user informs the network to charge a third user for the communication session between the first user and a second user. The charging of the third user could be for all or only some media types involved in the session. The first user and the second user communicate with each other and the network charges the third user for the communication session. A user requests for session cost related information from the IMS/SIP network and the user obtains the session cost related information from the IMS/SIP network. The user decides to engage in said communication session based on said session cost related information. The first user or the second user informs the network to charge a third user for the communication session using charging information in Session Initiation Protocol (SIP). The first user or the second user informs the network to charge a third user for the communication session by indicating charging indicator as "other" in the charging information. The charging indicator can be indicated as "other" in at least one of INVITE message, RE-INVITE message, UPDATE message, 18x response message 200 OK message and ACK message. The first user or the second user sends identity of the third user to the IMS/SIP network along with the charging information. The first user or the second user sends the identity of the third user to the IMS/SIP network when the communication session is being set up or the first user or second user sends the identity of the third user to the IMS/SIP network during the communication session. The session cost related information is sent in P-Charge-Info header in Session Initiation Protocol.

[006] Embodiments further disclose a system for charging users for a communication session in IMS/SIP networks. A first user or the second user informs the network to charge a third user for the communication session between the first user and a second user. The first user and the second user communicate with each other and the network charges the third user for the communication session. A user requests for session cost related information from the IMS/SIP network and the user obtains the session cost related information from the IMS/SIP network. The user decides to engage in said communication session based on said session cost related information. The first user informs the network to charge a third user for the communication session using charging information in Session Initiation Protocol (SIP). The first user or the second user sends an identity of the third user to the IMS/SIP network along with the charging information. The first user or the second user informs the network to charge a third user for the communication session by indicating charging indicator as "other" in the charging information. The charging indicator can be indicated as "other" in at least one of INVITE message, RE-INVITE message, UPDATE message, 18x response message, 200 OK message and ACK message.

[007] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES [008] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:

[009] FIG. 1 illustrates a block diagram of IMS networks, according to an embodiment herein;

[0010] FIG. 2 is a flow diagram illustrating an example showing the basic charging indicator framework in SIP networks, according to an embodiment herein;

[001 1] FIGS. 3a and 3b are flow diagrams illustrating an example showing the basic charging indicator framework in IMS networks, according to an embodiment herein;

[0012] FIG. 4 is a flow diagram illustrating an example showing the charging offer- charging answer model in SIP networks, according to an embodiment herein;

[0013] FIGS. 5a, 5b, 5c and 5d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having offline charging and user B 102 having online charging, according to an embodiment herein;

[0014] FIGS. 6a, 6b, 6c and 6d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having online charging and user B 102 having offline charging, according to an embodiment herein;

[0015] FIGS. 7a, 7b, 7c and 7d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having online charging and user B 102 having offline charging and the session cost related information being transported, according to an embodiment herein;

DETAILED DESCRIPTION OF EMBODIMENTS

[0016] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0017] The embodiments herein disclose a system and method for allowing a third user to be charged for all or some of the involved media types in a communication session between the calling user and the called user. Also, a user can know the cost related information for a communication session. Referring now to the drawings, and more particularly to FIGS. 1 through 7, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.

[0018] FIG. 1 illustrates a block diagram of IMS networks. A user of the network may be a calling user or the called user. The calling user may be referred to as user A 101 and the called user may be referred to as user B 102. When user A 101 wishes to communicate with user B 102, user A 101 initiates a communication session with user B 102 through the network. The network may be an Internet Protocol Multimedia Subsystem (IMS) network or a Session Initiation Protocol (SIP) network. User A 101 and user B 102 may belong to the same network or they may belong to different networks. Establishment of IMS based communication sessions involve negotiation of media capabilities between the users involved in the session. IMS network comprises of Home Subscriber network (HSS) 107, Application server (AS) 108, Interrogating Call Session Control Function (I-CSCF) 106, Serving Call Session Control Function (S-CSCF) 105, Proxy Call Session Control Function (P-CSCF) 103, Charging Module (CM) 109, Media Resource Function (MRF) 104. The HSS 107 is a master repository that supports the IMS entities which handle the communication sessions. HSS 107 contains subscription related information from the user profile, performs authentication, authorization of the user and includes information about the identity of the user, roaming profile etc. The AS 108 hosts and executes the service and interfaces with the S- CSCF 105 using SIP. Depending on the actual mode of service, the S-CSCF 105 can operate in SIP proxy mode or SIP user agent mode. AS 108 may reside in the home network or in an external network. Charging related information available in the user profile is examined by the AS 108. During the session set up phase, the AS 108 takes appropriate actions and triggers appropriate charging related information to be passed in the protocol messages. AS 108 plays the role of Originating Charging Determinant (OCD) or Terminating Charging Determinant (TCD) depending on whether the AS 108 is at the originating side or the terminating side. The origination charging determinant (OCD) is the first proxy from user A 101 to user B 102. In case of IMS networks, the OCD is typically the AS 108 of the calling user. The OCD may also be the S-CSCF 105 of the calling user. The terminating charging determinant (TCD) is the last proxy from user A 101 to user B 102. In case of IMS networks, the TCD could also be the AS 108 or S-CSCF 105 of the called user. Error or unsuccessful negotiation cases are handled by the AS 108. Several roles of SIP servers or proxies collectively called as Call Session Control functions (CSCF) are used to process SIP packets in the IMS. P-CSCF 103 is a SIP proxy and is the first point of contact for the IMS terminal. P-CSCF 103 is in the path of all signaling messages and inspects every single message. P- CSCF 103 authenticates the user and establishes security association with the IMS terminal. In the basic charging framework, P-CSCF 103 is responsible for removing the application body containing the charging related information from the message before sending it to the user. P-CSCF 103 also stores the received charging related information, and informs the charging functions accordingly. S-CSCF 105 is the central node of signaling plane. S-CSCF 105 is a SIP server that performs session control functions too. S-CSCF 105 may use DIAMETER protocol interfaces to the HSS 107 to download and upload user profiles. Also, the S-CSCF 105 assigns the application server 108, to which the SIP message sent by the calling user will be forwarded. The S-CSCF 105 triggers the AS 108 during the session set up phase. If the AS 108 is not involved in the session flow, the S-CSCF takes up the responsibility of carrying out the functions performed by the AS 108. I-CSCF 106 is located in the administrative domain. I-CSCF 106 queries the HSS 107 to retrieve user information and routes the SIP request to the assigned S-CSCF 105. Media Resource Function (MRF) 104 provides media related functions such as media manipulation and playing of announcements and tones. The Charging Module (CM) performs all charging related functions in the network. The CM may be the Online charging System (OCS) or the Charging Data Function (CDF). The OCS is the CM 109 if the user 101 is an online charged user and the CDF is the CM 109 if the user 101 is an offline charged user. The Online charging System (OCS) provides a mechanism for charging the user for the sessions. OCS is similar to a prepaid charging mechanism wherein the user has to hold some credits initially. The OCS comprises of Session Control Function (SCF) and Event Charging Function (ECF). The charges for the session are deducted from the user's account. The Charging Data Function (CDF) keeps a track of the data related to charging. In OCS, the S-CSCF 105 interacts with the Session Control Function (SCF) that is similar to the SIP application server. SCF signals the S-CSCF 105 to terminate the session when the user runs out of credits in his account during a session. In Event Charging with Unit Reservation (ECUR), the Event Charging Function (ECF) reserves the number of credit units in the user's account and then authorizes the MRF 104 or the AS 108 for charging. After the service is complete, the number of credit units is reported and deducted from the user's account. The reserved credit units are then cleared.

[0019] User A 101 initiates a session to user B 102 by sending an invitation message. User A 101 can choose to have a third user be charged for the session by including charging related information in the invitation message. The third user may be user C 101 or user D 101. The charging related information could be included in SIP as application/sdp, ci. Details such as the type of the media content delivered and charging information is also present in the application/sdp, ci body. Charging indicator indicates what part of the session is charged to different users. The body format of the charging indicator would indicate the sdp media type and the party being charged for the communication session. The body format could be as sdpMedia = audio/video/default and the charging indicator could indicate the charged party as sdpCi = caller/called/none/both/other. Alternatively, the media and charging indicator could also be included in SIP by including an extra "ci=" line for each "m=" line in Session Description Protocol (SDP), with ci = caller/called/none/both/other. sdpMedia and 'm' indicate the media type to be charged for a particular user and 'ci' indicates the user who is to be charged for the call. If sdpMedia or 'm' = audio, then it indicates that the charging information is for the audio, if sdpMedia or 'm' = video, then it indicates that the charging information is for the video. If sdpMedia = default, then it indicates that the charging information is for all media types. If sdpCi = caller, then it indicates that the calling user would be charged for the particular media type, if sdpCi = called, then it indicates that the called user would be charged for the particular media type, if sdpCi = none, then it indicates that the none of the users would be charged for the particular media type, if sdpCi = both, then it indicates that both users would be charged for the particular media type and if sdpCi = other, then it indicates that a third user would be charged for the particular media type. The charging indicator can be indicated as "other" in at least one of INVITE message, RE-INVITE message, UPDATE message, 18x response message 200 OK message and ACK message. The user A 101 may wish to have a friend be charged for the session. If a third party is being charged for the communication session, then user A 101 also sends the third user's identity along with the invitation message. For example, the identity of the third user may be the telephone number of the third user. The P-Charge-Info header may also be used for sending the third user's identity. The P-Charge-Info header can be filled in by the network based on information stored in the user's profile or can be filled in by user A 101. Before sending the third user's identity, user A 101 stores the identity with the network and when user A 101 sends the third user's identity, the network checks to determine if the identity is included in user A's 101 profile. The network allows user A 101 to have the third party be charged for the session if the identity of the third user has been included in user A's 101 profile. In other embodiments, user A 101 may dynamically enter the identity of the third user during the session. For example, if user A 101 is in a communication session with user B 102 and midway through the session, user A 101 realizes that user A does not have enough currency balance in the account to continue the session, then user A 101 can enter the identity of a third user and have the third user be charged for the remaining part of the session. If 'sdpCi' or 'ci' indicates "other", but information regarding the third user's identity is not transported, then either a default value may be taken to be charged user for the session or the invitation sent may not be accepted by the network or the network operator. For example, the default value chosen may be 'calling' to indicate that user A 101 would be charged for the session and the default value may be indicated in a response sent to the invitation. If the invitation is not accepted, then the network may send a 418 Charging Indicator Not Acceptable response to user A 101 when the charging offer was sent in an invitation or a RE-INVITE message. If the charging offer was sent in a response to the invitation, then the session may be released. The response to an invitation may be sent as a 200 OK message. If 'sdpCi' or 'ci' indicates "both", and a header containing a third user's identity is also transported and if the charging offer was initiated by user A 101 or user A's 101 network, then user B 102 and the third user would be charged for the session. If 'sdpCi' or 'ci' indicates "both", and a header containing a third user's identity is also transported and if the charging offer was initiated by user B 102 or user B's 101 network, then user A 101 and the third user would be charged for the session. If the charging offer was initiated with 'sdpCi' or 'ci' indicating "other" or "both", then the answer to the charging offer can indicate "both" and an additional header including the user to be charged. For example, if P-Charge-Info header was used to transport the third user's identity, the header would be repeated 2 times, one for the user who initiates the charging offer and the other for the user answering the offer. Multiple users may be charged for multiple different media types. For example, a third user and a fourth user may also be charged for the communication session. The third user may be charged for the video and the fourth user may be charged for the audio. The P-Charge-Info header would be included multiple times to indicate the multiple users to be charged for the session. The order of multiple occurrences of the P-Charge-Info header in would correspond to the order in which the media types are listed in the application/sdp, ci body. The P-Charge-Info header may also be extended to also include the media type associated, or a different header or the application/sdp, ci body layout may be employed to convey the information about the media. If user A 101/user B 102 and "other" parties are to be charged for the session, then the indication "both" would be included in the charging offer. For example, the indication may be added along with the P-Charge-Info header. A proper charging decision would be made depending on the direction in which the indication is included. For example, if the invitation message indicates "both", then user B 102 and the third user would be charged for the session. If the 200 OK message indicates "both", then user A 101 and the third user would be charged for the session (assuming the third user's identity was provided by User B 102 or User B 102's network). The identity of the third user being charged for the call may also be changed when a communication session between user A 101 and user B 102 is in progress. For example, if user A 101 is speaking to user B 102 and a third user is being charged for the call, then after sometime user A 101 can choose to make a fourth user be charged for the remaining duration of the call.

[0020] If a user needs to know the charges applicable for the communication session, then the session cost related information can also be sent along with SIP application body. A user may decide to accept the charging offer after knowing the charges applicable for the session. The session cost related information may be sent in the charging offer and/or the answer to the charging offer. The session cost related information may also be sent only in the charging answer on receiving a request for the cost related information in the charging offer. For example, the session cost related information may be sent in the application/sdp, ci body. The session cost related information may be sent in Attribute Value Pair's (A VP's) in DIAMETER protocol. Cost-Unit AVP can be used to inform the user of the cost involved. Additional information can be transported in the Cost-Information AVP, Tariff-Time-Change AVP, Service-Units AVP (which can be a new AVP with similar syntax as Requested-Service-Units AVP), etc. The originating/terminating network could convert the standard AVP formats into user-friendly formats, such as readable strings, within a particular network. In case of updating the user to be charged for the entire session, after the session is in progress (using a Re- INVITE), information such as cost accumulated till the instant of processing the Re-INVITE can also be included in addition to including the pulse rate, units, etc. The session cost related information may also be sent in a format that is similar to the Charged Number parameter contents used in ISDN User Part (ISUP). The charging units (or pulse rate) can be transported by after the originating/terminating network converts the charging units into a user-friendly format. The request for the cost related information may be included in the SIP application body in the format "Session-cost-information-requested: Yes". Once the request for the cost related information is received, the network receiving the charging offer ensures that the session cost related information is included in the charging answer. If the network/user requesting for session cost related information, in the charging offer, does not receive the for the cost related information in the charging answer, then the network/user may decide to terminate the session or continue with the session and optionally send a fresh charging offer.

[0021] The proxy server is responsible for inserting the charging related information in the application body of the message and is inserted only in the new application body. The proxy server checks the profile settings of the user to determine if the user has authorization for transmitting a particular content. The proxy server also examines any information related to charging indicator, during the session set up phase, to take appropriate actions and trigger the appropriate charge indicator information to be passed. The proxy server interacts with the charging functions on receiving information from the charging indicator. In network level manipulation method, user's preferences are stored in the proxy server. Details like reverse charging acceptable or not, event based charging facilities, etc are stored in the proxy server. When the session is initiated by user A 101 by sending an invitation message, the invitation message is sent to the proxy server of the network of user A 101. The proxy server checks for the profile settings of the user A 101 and accordingly inserts the application body contents in the invitation message. Default settings for a user could be present in the user's profile for a particular charging indicator for sessions to certain users or sessions involving certain media types. The default settings information is passed to the proxy server by the subscriber database as part of the user profile information. Also, reverse charging can be defined in the subscriber database and may be applicable for all incoming sessions or may be selective depending on certain pre-defined criteria. The proxy server inserts the charging indicator related information in the application body of the message, whereas the SDP part is already inserted by the calling user in the application body when user A 101 sends the invitation message. The invitation message is sent to the proxy server of user B 102. The proxy server removes the charging indicator related information from the application body of the invitation message before the invitation message is sent to the user B 102. The OCD is the first proxy from user A 101 to user B 102 that manipulates the charging related information in the application body of the invitation message. The TCD is the last proxy from user A 101 to user B 102 that manipulates the charging related information in the application body of the invitation message. In embodiments disclosed herein, the AS 108 or the S-CSCF 105 may function as the proxy server, and the HSS 107 may function as the subscriber database.

[0022] In case of an offer answer model for charging, user A 101 initiates a communication session through the originating network to user B 102. User A 101 sends an invitation message with the SIP application body. The application body may include the offer for charging. The invitation message is sent to user B 102 through the network elements. User B 102 may accept the offer and continue the session by sending a response to the invitation, whereas, if the offer is not acceptable to user B 102, the offer is rejected and a response indicating the rejection is sent by user B 102 to user A 101. Further, user A 102 may send a RE-INVITE message with a new offer and the session may continue. Error or unsuccessful scenarios are handled by the AS 108, for example, considering the case wherein the user A 101 belongs to one network and user B 102 belongs to another network 104. The charging information or offer made by one network may not acceptable to the other network 104, for example, if the originating network inserts the charging indicator as 'called' and the terminating network does not facilitate reverse charging. In such case, the offer is not accepted and the session may be terminated by sending a response message or the session may be accepted and an update message is sent with the charging indicator as 'calling'. If the offer is not acceptable by the originating network, the session may be terminated.

[0023] User A 101 or user B 102 could have updated information about a third user, to be charged for a communication session, in the user profile. The network could use information about the third user when 'sdpCi' or 'ci' indicates "other" or "both". User A 101 or user B 102 could update information about multiple users who could be chosen to be charged for a communication session. The charging indicator, 'sdpCi' or 'ci', can be updated by the TCD and/or OCD and the rules for updating the charging indicator by the TCD is illustrated in Table 1 and the rules for updating the charging indicator by the OCD is illustrated in Table 2.

Other Not Allowed Not Allowed Not Allowed Allowed Allowed

Both Not Allowed Allowed Not Allowed Allowed Allowed

fABLE 1

Both Not Allowed Not Allowed Allowed Allowed Allowed

fABLE 2

[0024] When the TCD updates the charging indicator from "none" or "called" to "other", then a third user belonging to the network of user B 102 will be charged. The TCD can also indicate an (additional) alternate charged user in the response message, and update the charging indicator from "caller" or "other" to "both". If the identity of the third user was received from the OCD then a third user, belonging to the network of the OCD, shall be charged for the session, when the TCD updates the charging indicator from "both" to "other". When the OCD updates the charging indicator from "none" or "caller" to "other", then the third user would belong to the network of user A 101. The OCD can also indicate an alternate user, to be charged for the session, in the response message, and update the charging indicator from "called" or "other" to "both". If the identity of the third user was received from the TCD then a third user, belonging to the network of the TCD, shall be charged for the session, when the OCD updates the charging indicator from "both" to "other". The OCD and the TCD can also request for the session cost related information. For example, the OCD and the TCD may request for the session cost related information when sending the application/sdp, ci body. When the request for the session cost related information is received by the network, the network could send the session cost related information to the users.

[0025] FIG. 2 is a flow diagram for an example showing the basic charging indicator framework in SIP networks. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 203 message towards user B 102 to start the communication session. User A 101 can choose to have user B 102 or a third user be charged for the session, and this information could be present in the user profile of User A 101, stored in the network of User A 101 (and accessible by Proxy A 201). The invitation message sent by user A 101 would be received by proxy A 201 in the network of user A 101. Based on the profile of user A 101 or on the service logic, proxy A 201 inserts the application/sdp, ci body to the invitation message and sends the invitation message towards the network of user B 102. For example, the charging information in the application/sdp, ci body could be made up of the charging indicator and the charging indicator may specify the charged party as "other". The invitation message may also indicate the media type that the third user would be charged for. Proxy A 201 also sends the identity of the third user to the network of User B 102. For example, proxy A 201 may send an INVITE 204 message towards the network of user B 102. The message sent by proxy A 201 would be received by proxy B 202 in the network of user B 102. Proxy B 202 removes the application/sdp, ci body from the invitation message, stores the removed application/sdp, ci body and sends the invitation to user B 102. For example, Proxy B 202 may send the INVITE 205 message to user B 102. On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. For example, user B 102 may send a 200 OK 206 response message towards user A 101. The response sent by user B 102 would be received by proxy B 202 and proxy B 202 updates the stored application/sdp, ci body. Proxy B 202 updates the charging information based on the profile of user B 102 or on the service logic. For example, the audio part may be free and the video part may be charged to a third user whose identity is available with proxy B 202. Proxy B 202 then inserts the application/sdp, ci body into the response message and sends the response message to user A 101 through proxy A 201. For example, the response message sent by proxy 202 towards Proxy A 101 may be a 200 OK 207 message. Proxy A, in turn, removes the application/sdp,ci body in the received 200 OK after storing it and acting upon it appropriately, before sending the 200 OK 208 message towards User A.

[0026] FIGS. 3a and 3b are flow diagrams illustrating an example showing the basic charging indicator framework in IMS networks. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 301 message towards P-CSCF A 103 to send it towards user B 102 to start the communication session. User A 101 can choose to have user B 102 or a third user be charged for the session, and this information could be present in the user profile of User A 101, stored in the network of User A 101 (and accessible by the S-CSCF A 105/AS A 108). The invitation message sent by user A 101 would be received by AS A 108 after passing through P-CSCF A 103 and S-CSCF A 105. For example, the message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a INVITE 302 message and the message sent by the S-CSCF A 105 to AS A 108 may be a INVITE 303 message. Based on the profile of user A 101 or on the service logic, AS A 108 inserts the application/sdp, ci body to the invitation message. In order to have a third user be charged for the session, AS A 108 indicates that a third user would be charged for the session by sending the charging information as part of the application/sdp, ci body in the invitation message. The invitation message may also indicate the media type that the third user would be charged for. AS A 108 also includes the identity of the third user in the invitation message. AS-A 108 sends the updated invitation message to the S-CSCF A 105. For example, AS A 108 may send an INVITE 304 message to the S-CSCF A 105. The S-CSCF A 105 sends the invitation message to P-CSCF B 103 through I- CSCF B 106, S-CSCF B 105 and AS B 108. For example, the message sent by the S-CSCF A 105 to the I-CSCF B 106 may be an INVITE 305 message. The message sent by the I-CSCF B 106 to the S-CSCF B 105 may be an INVITE 306 message and the message sent by the S-CSCF B 105 to AS B 108 may be an INVITE 307 message. The AS B 108 sends the invitation message back to the S-CSCF B 105 and the S-CSCF B 105 sends the invitation message to the P-CSCF B 103. For example, the message sent by the AS B 108 to the S-CSCF B 105 may be an INVITE 308 message and the message sent by the S-CSCF B 105 to the P-CSCF B 103 may be an INVITE 309 message. The P-CSCF B 103 removes the application/sdp, ci body from the invitation message, stores the removed application/sdp, ci body and sends the invitation to user B 102. For example, the message sent by the P-CSCF B 103 to user B 102 may be an INVITE 3010 message.

[0027] On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. For example, user B 102 may send a 200 OK 3011 response message towards P-CSCF B 103 to be sent towards user A 101. The response sent by user B 102 would be received by P-CSCF B 103. The P-CSCF B 103 inserts the application/sdp, ci body into the response message and sends the response message to AS B 108 through the S-CSCF B 105. For example, the response message sent by the P-CSCF B 103 to S-CSCF B 105 may be a 200 OK 3012 message and the message sent by the S-CSCF B 105 to AS B 108 is a 200 OK 3013 message. AS B 108 updates the charging information based on the profile of user B 102 or on the service logic and sends the response to user A 101 through the S-CSCF B 105, the S-CSCF A 105, the AS A 108 and the P-CSCF A 103. For example, the message sent by the AS B 108 to the S- CSCF B 105 may be a 200 OK 3014 message, the message sent by the S-CSCF B 105 to the S- CSCF A 105 may be a 200 OK 3015 message and the message sent by the S-CSCF A 105 to AS A 108 may be a 200 OK 3016 message. The AS A 108 sends the response message back to the S- CSCF A 105. For example, the message sent by the AS A 108 to the S-CSCF A 105 may be a 200 OK 3017 message, the message sent by the S-CSCF A 105 to the P-CSCF A 103 may be a 200 OK 3018 message. The P-CSCF A 103 removes the application/sdp,ci body in the received 200 OK message before sending it towards User A 101. For example, the message sent by the P-CSCF A 103 to user A 101 may be a 200 OK 3019 message.

[0028] FIG. 4 is a flow diagram illustrating an example showing the charging offer- charging answer model in SIP networks. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 401 message towards user B 102 to start the communication session. User A 101 can choose to have user B 102 be charged for the session. In order to have user B 102 be charged for the session, user A 101 indicates that user B 102 would be charged for the session by sending the charging information in the invitation message. For example, the charging information could be made up of the charging indicator and the charging indicator may specify the charged party as "called". The invitation message may also indicate the media type that user B 102 would be charged for. The invitation message sent by user A 101 would be received by proxy A 201 in the network of user A 101. Proxy A 201 checks the charging information in the invitation message and determines the media type to be charged for a particular user. Proxy A 201 updates the application/sdp, ci body in the invitation message, based on the check. For example, proxy A 201 may determine that user B 102 would be charged for the audio part of the communication session. Proxy A 201 also interacts with the charging functions. User A 101 and user 102 may have online charging or offline charging. For example, an offline charged user may be a postpaid user and an online user maybe a prepaid user. Proxy A 201 sends the invitation message towards the network of user B 102. For example, proxy A 201 may send an INVITE 402 message towards the network of user B 102, which is processed by Proxy B 202. Proxy B 202 sends the invitation to user B 102. For example, Proxy B 202 may send the INVITE 403 message to user B 102. On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. User B 102 may also choose to have a third user, in user B's 102 network, be charged for the session. If user B 102 wants to have a third user be charged for the session, then user B 102 updates the charging information to indicate that a third user would be charged for the session. User B 102 also sends the identity of the third user to the network in the response message. User B 102 then sends the new charging information, towards user A 101, in a response to the invitation. For example, user B 102 may send a 200 OK 404 message towards user A 101 through proxy B 202 and proxy A 201. The message sent by proxy B 202 to proxy A 201 may be a 200 OK 405 message and the message sent by proxy A 201 to user A 101 may be a 200 OK 406 message.

[0029] On receiving the response from user B 102, user A 101 may change the charging information. User A 101 may want to become the charged party for the session and user A 101 updates the charging information accordingly. User A 101 sends the fresh charging offer towards user B 102. For example, user A 101 may send the fresh charging offer in a Re-INVITE 407 message through proxy A 201 and proxy B 202. For example, the message sent by proxy A 201 to proxy B 202 may be a Re-INVITE 408 message and the message sent by proxy B 202 to user B 102 may be a Re-INVITE 409 message. User B 102 may choose to accept the invitation and the new charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. For example, user B 102 may send a 200 OK 4010 response message towards user A 101 through proxy B 202 and proxy A 201. For example, the message sent by proxy B 202 to proxy A 201 may be a 200 OK 4011 message and the message sent by proxy A 201 to user A 101 may be a 200 OK 4012 message. In some cases, it is also possible that User B 102 has information stored in its profile in Proxy B 202, which could result in Proxy B 202 taking a decision to either send the INVITE or Re-INVITE message containing the charging offer towards User B 102, or to reject the INVITE or Re-INVITE message containing the charging offer.

[0030] FIGS. 5a, 5b, 5c and 5d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having offline charging and user B 102 having online charging. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 501 message towards user B 102 to start the communication session. User A 101 can choose to have user B 102 or a third user be charged for the session. User A 101 may wish to make user B 102 as the charged party for the call, by sending the charging information in the invitation message. The invitation message may also indicate the media type that the called user would be charged for. The invitation message sent by user A 101 would be received by the AS A 108 after passing through P-CSCF A 103 and S-CSCF A 105. For example, the message sent by the P-CSCF A 103 to the S-CSCF A 105 may be an INVITE 502 message and the message sent by the S-CSCF A 105 to AS A 108 may be an INVITE 503 message. Based on the profile of user A 101, AS A 108 may check if user A 101 is allowed to include the charging information in the invitation message. AS A 108 could also include the session cost related information in the invitation message before sending the invitation message to the S-CSCF A 105. For example, the session cost related information may be the pulse rate for the call and the AS A 108 may send an INVITE 504 message to the S-CSCF A 105. The S-CSCF A 105 sends the invitation message to AS B 108 through I-CSCF B 106 and S-CSCF B 105. For example, the message sent by the S-CSCF A 105 to the I-CSCF B 106 may be an INVITE 505 message, the message sent by the I-CSCF B 106 to the S-CSCF B 105 may be an INVITE 506 message and the message sent by the S-CSCF B 105 to the AS B 108 may be an INVITE 507 message. [0031] The AS B 108 checks the profile of user B 102 and/or the service logic for the session request. Based on the check, the AS B 108 may determine the charging for different media types involved in the session. For example, after the check, AS B 108 may determine that the video part is free for the particular communication session. After the profile check if it is determined that both the users have offline charging, then the AS B 108 may inform the charging function through an attribute value pair in the IMS information attribute value pair about the particular party to be charged for the particular media type. The attribute value pair may be included in the accounting request. An offline charged user may be a postpaid user, the charging function may be the CDF, the Attribute value pair (AVP) may be the Media-Based-Charging-Info AVP. An AVP includes a header and is used to encapsulate protocol-specific data as well as authentication, authorization or accounting information. The accounting request may be an Accounting Request (ACR) message. The Media-Based-Charging-Info AVP may be included in the IMS-Information AVP in the ACR. If it is determined that both the users have online charging, then the serving application may inform the charging function through an attribute value pair in the IMS information AVP about the particular party to be charged for the particular media type. An online user maybe a prepaid user and for an online user the charging function may be the OCS. The attribute value pair may be included in the credit request and for an online user the credit request may be the Credit control request (CCR). The media related information may be a part of the Service- Information AVP in the CCR message, and the Service-Information AVP, in turn, contains the IMS-Information AVP. If it is determined that user A 101 has online charging and user B 102 has offline charging then the accounting request from AS B 108 to the charging function and the credit request from AS A 108 may include the new attribute value pair (for example, called as Media-Based-Charging-Info AVP) in the IMS-Information AVP. The accounting request from the AS B 108 to the charging function may be the ACR and the credit request from the AS A 108 may be the CCR. The CCR sent from AS B 108 may contain the extended Service-Information AVP. If it is determined that user A 101 has offline charging and user B 102 has online charging then the accounting request from AS A 108 towards the charging function and the credit request from AS B 108 may include the new attribute value pair (for example, called as Media-Based-Charging-Info AVP) in the IMS-Information AVP. The accounting request from AS A 108 to the charging function may be the ACR and the credit request from AS B 108 may be the CCR.. The AS B 108 may send the credit request to the OCS B (shown as CM B 109 in the figure). For example, the message sent by AS B 108 to the OCS B may be a CCR 508. The OCS sends an acknowledgement back to the AS B 108. The acknowledgement may be a Credit control answer (CCA) 509.

[0032] AS B 108 updates the charging information in the invitation message and sends the invitation message to user B 102 through the S-CSCF B 105 and the P-CSCF B 103. For example, the message sent by the AS B 108 to the S-CSCF B 105 may be an INVITE 5010 message, the message sent by the S-CSCF B 105 to the P-CSCF B 103 may be an INVITE 501 1 message and the message sent by the P-CSCF B 103 to user B 102 may be an INVITE 5012 message. On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. User B 102 may also choose to have a third user, in user B's 102 network, be charged for the session. If user B 102 wants to have a third user be charged for the session, then user B 102 updates the charging information to indicate that a third user would be charged for the session. User B 102 also sends the identity of the third user to the network. User B 102 then sends the new charging information, towards user A 101, in a response to the invitation. For example, user B 102 may send a 200 OK 5013 response message towards user A 101 and the response message may indicate that a third user would be charged for the audio and the video would be free for the session. The response sent by user B 102 would be received by P-CSCF B 103. P-CSCF B 103 sends the response towards AS A 108 through the S-CSCF B 105, AS B 108 and the S-CSCF A 105. For example, the message sent by the P-CSCF B 103 to the S-CSCF B 105 may be a 200 OK 5014 message, the message sent by the S-CSCF B 105 to the AS B 108 may be a 200 OK 5015 message, the message sent by AS B 108 back to the S-CSCF B 105 may be a 200 OK 5016 message, the message sent by the S-CSCF B 105 to the S-CSCF A 105 may be a 200 OK 5017 message and the message sent by the S-CSCF A 105 to the AS A 108 may be a 200 OK 5018 message. AS A 108 sends an accounting request to the CDF A (shown as CM A 109 in the figure) and the CDF A sends an acknowledgement back to AS A 108. For example, the accounting request may be an ACR 5019 and the acknowledgement may be an ACA 5020. The AS A 108 then sends the response received from user B 102 to user A 101 through the S-CSCF A 105 and the P-CSCF A 103. For example, the response sent by AS A 108 to the S-CSCF A 105 may be a 200 OK 5021 message, the response sent by the S-CSCF A 105 to the P-CSCF A 103 may be a 200 OK 5022 message and the response sent by the P-CSCF A 103 to user A 101 may be a 200 OK 5023 message.

[0033] On receiving the response from user B 102, the session continues after User A 101 sends an acknowledgement to User B 102. After some time, user A 101 may want to change the charged user for the session. For example, user A 101 may want to become the charged party for the session. In such a case, user A 101 updates the charging information accordingly and sends the fresh charging offer towards user B 102. For example, user A 101 may send the fresh charging offer in a RE-INVITE 5024 message. The re-invitation message would be received by P-CSCF A 103 and P-CSCF A 103 sends the re-invitation message to AS B 108 through S-CSCF A 105, AS A 108 and S-CSCF B 105. For example, the re-invitation message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a RE-INVITE 5025 message, the re- invitation message sent by the S- CSCF A 105 to AS A 108 may be a RE-INVITE 5026 message, the re- invitation message sent by AS A 108 back to the S-CSCF A 105 may be a RE-INVITE 5027 message, the re-invitation message sent by the S-CSCF A 105 to the S-CSCF B 105 may be a RE-INVITE 5028 message and the re-invitation message sent by the S-CSCF B 105 to AS B 108 may be a RE-INVITE 5029 message.

[0034] Since the charging information has been updated by user A 101, AS B 108 sends a credit request to the OCS B and the OCS B sends an acknowledgement back to AS B 108. For example, the credit request may be a CCR 5030 and the acknowledgement may be a CCA 5031. AS B 108 then sends the re- invitation message to user B 102 through the S-CSCF B 105 and the P-CSCF B 103. For example, the re-invitation message sent by AS B 108 to the S-CSCF B 105 may be a RE-INVITE 5032 message, the re- invitation message sent by the S-CSCF B 105 to the P-CSCF B 103 may be a RE-INVITE 5033 message and the re-invitation message sent by the P- CSCF B 103 to user B 102 may be a RE-INVITE 5034 message.

[0035] User B 102 may choose to accept the invitation and the new charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. For example, user B 102 may send a 200 OK 5035 response message towards user A 101. The response would also include the new charging information. The response would be received by the P-CSCF B 103 and the P-CSCF B 103 sends the response to AS A 108 through the S-CSCF B 105, AS B 108 and S-CSCF A 105. For example, the response sent by the P-CSCF B 103 to the S-CSCF B 105 may be a 200 OK 5036 message, the response sent by the S-CSCF B 105 to AS B 108 may be a 200 OK 5037 message, the response sent back to the by AS B 108 to the S-CSCF B 105 may be a 200 OK 5038 message, the response sent by the S-CSCF B 105 to the S-CSCF A 105 may be a 200 OK 5039 message, the response sent by the S-CSCF A 105 to AS A 108 may be a 200 OK 5040 message. AS A 108 sends an accounting request to the CDF A and the CDF A sends an acknowledgement back to AS A 108. For example, the accounting request may be an ACR 5041 message and the acknowledgement may be an ACA 5042 message. The AS A 108 then sends the response received from user B 102 to user A 101 through the S-CSCF A 105 and the P-CSCF A 103. For example, the message sent by AS A 108 to the S-CSCF A 105 may be a 200 OK 5043 message, the message sent by the S-CSCF A 105 to the P-CSCF A 103 may be a 200 OK 5044 message and the message sent by the P-CSCF A 103 to user A 101 may be a 200 OK 5045 message. The session continues thereafter (after User A 101 sends an acknowledgement to User B 102), since the charging offer made by User A 101 has been successfully answered by User B 102.

[0036] FIGS. 6a, 6b, 6c and 6d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having online charging and user B 102 having offline charging. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 601 message towards user B 102 to start the communication session. User A 101 can choose to have user B 102 or a third user be charged for the session. User A 101 may wish to make user B 102 as the charged party for the call, by sending the charging information in the invitation message. The invitation message may also indicate the media type that the called user would be charged for. The invitation message sent by user A 101 would be received by the AS A 108 after passing through P-CSCF A 103 and S-CSCF A 105. For example, the message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a INVITE 602 message and the message sent by the S-CSCF A 105 to AS A 108 may be a INVITE 603 message. Based on the profile of user A 101, AS A 108 may check if user A 101 is allowed to include the charging information in the invitation message. The AS A 108 checks the profile of user A 101 and/or the service logic for the session request. Since User A 101 has online charging, AS A 108 sends a credit request message towards the OCS A (shown as CM A 109 in the figure). The credit request may contain the Media-Based-Charging-Info AVP inside the IMS- Information AVP, which is, in turn, included in the Service-Information AVP. For example, the message sent by AS A 108 to the OCS A may be a CCR 604. The OCS A sends an acknowledgement back to AS A 108. The acknowledgement may be a CCA 605.

[0037] AS A 108 sends the invitation message to AS B 108 through the S-CSCF A 105, 1- CSCF B 106 and S-CSCF B 105. For example, the message sent by AS A 108 to the S-CSCF A 105 may be an INVITE 606 message, the message sent by the S-CSCF A 105 to the I-CSCF B 106 may be an INVITE 607 message, the message sent by the I-CSCF B 106 to the S-CSCF B 105 may be an INVITE 608 message and the message sent by the S-CSCF B 105 to AS B 108 may be an INVITE 609 message. The AS B 108 checks the profile of user B 102 and/or the service logic for the session request. Based on the check, the AS B 108 may determine the charging for different media types involved in the session. For example, after the check, AS B 108 may determine that the video part is free for the particular communication session. The AS B 108 includes the charging information for different media types and sends the invitation message to user B 102 through the S-CSCF B 105 and the P-CSCF B 103. For example, the message sent by AS B 108 to the S-CSCF B 105 may be an INVITE 6010 message, the message sent by the S- CSCF B 105 to the P-CSCF B 103 may be an INVITE 6011 message and the message sent by the P-CSCF B 103 to the user B 102 may be an INVITE 6012 message.

[0038] On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. User B 102 may also choose to have a third user, in user B's network, be charged for the session. If user B wants to have a third user be charged for the session, then user B 102 updates the charging information to indicate that a third user would be charged for the session. User B 102 also sends the identity of the third user to the network in the response message. User B 102 then sends the new charging information, towards user A 101, in a response to the invitation. For example, user B 102 may send a 200 OK 6013 response message towards user A 101 and the response message may indicate that a third user would be charged for the audio and the video would be free for the session. The response sent by user B 102 would be received by P-CSCF B 103. P-CSCF B 103 sends the response to AS B 108 through the S-CSCF B 105. For example, the response sent by the P-CSCF B 103 to the S-CSCF B 105 may be a 200 OK 6014 message and the response sent by the S-CSCF B 105 to the AS B 108 may be a 200 OK 6015 message. AS B 108 sends an accounting request to the CDF B (shown as CM B 109 in the figure), containing the media-based charging information, transported, for example, in the Media- Based-Charging-Info AVP in the IMS -Information AVP. The CDF B sends an acknowledgement back to AS B 108. For example, the accounting request may be an ACR 6016 and the acknowledgement may be an ACA 6017. The AS B 108 then sends the response received from user B 102 to AS A 108 through the S-CSCF B 105 and the S-CSCF A 105. For example, the response sent by AS B 108 to the S-CSCF B 105 may be a 200 OK 6018 message, the response sent by the S-CSCF B 105 to the S-CSCF A 105 may be a 200 OK 6019 message and the response sent by the S-CSCF A 105 to AS A 108 may be a 200 OK 6020 message. AS A 108 sends a credit request update message to the OCS A. The credit request update message may include the Media- Based-Charging-Info AVP as a part of the IMS-Information AVP. The OCS A sends an acknowledgement to AS A 108. For example, the updated credit request may be a CCR 6021 message and the acknowledgement may be a CCA 6022 message. The AS A 108 then sends the response received from user B 102 to user A 101 through the S-CSCF A 105 and the P-CSCF A 103. For example, the message sent by AS A 108 to the S-CSCF A 105 may be a 200 OK 6023 message, the message sent by the S-CSCF A 105 to the P-CSCF A 103 may be a 200 OK 6024 message and the message sent by the P-CSCF A 103 to user A 101 may be a 200 OK 6025 message.

[0039] The communication session continues after user A 101 sends an acknowledgement to user B 102. After some time, user B 102 sends a re- invitation message towards user A 101 indicating the charging offer in the re- invitation message. User B 102 sends the re- invitation message towards user A 101 through the P-CSCF B 103, S-CSCF B 105, AS B 108 and S-CSCF A 105. For example, the re- invitation message sent by user B 102 to the P-CSCF B 103 may be a RE-INVITE 6026 message, the re-invitation message sent by P-CSCF B 103 to the S-CSCF B 105 may be a RE-INVITE 6027 message, the re-invitation message sent by the S-CSCF B 105 to AS B 108 may be a RE-INVITE 6028 message, the re- invitation message sent by the AS B 108 back to S-CSCF B 105 may be a RE-INVITE 6029 message, the re- invitation message sent by the S- CSCF B 105 to S-CSCF A 105 may be a RE-INVITE 6030 message and the re-invitation message sent by the S-CSCF A 105 to AS A 108 may be a RE-INVITE 6031.

[0040] Since there is an update in the charging information, AS A 108 sends a credit request update to the OCS A and the OCS A sends an acknowledgement to AS A 108. For example, the updated credit request may be a CCR 6032 message and acknowledgement may be a CCA 6033 message. AS A 108 then sends the re-invitation message to user A 101 through the S- CSCF A 105 and the P-CSCF A 103. For example, the re-invitation message sent by AS A 108 to the S-CSCF A 105 may be a RE-INVITE 6034 message, the re- invitation message sent by the S- CSCF A 105 to the P-CSCF A 103 may be a RE-INVITE 6035 message and the re-invitation message sent by the P-CSCF A 103 to user A 102 may be a RE-INVITE 6036 message.

[0041] User A 101 may choose to accept the re- invitation and the new charging offer or reject the re-invitation. If user A 101 accepts the invitation, then user A 101 sends a positive response towards user B 102. For example, user A 101 may send a 200 OK 6037 response message towards user B 102. The response would also include the new charging information. The response would be received by the P-CSCF A 103 and the P-CSCF A 103 sends the response to AS B 108 through the S-CSCF A 105, AS A 108, and S-CSCF B 105. For example, the re- invitation message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a 200 OK 6038 message, the re- invitation message sent by the S-CSCF A 105 to AS A 108 may be a 200 OK 6039 message, the re-invitation message sent by AS A 108 back to the S-CSCF A 105 may be a 200 OK 6040 message, the re-invitation message sent by the S-CSCF A 105 to the S-CSCF B 106 may be a 200 OK 6041 message, and the re- invitation message sent by the S-CSCF B 105 to AS B 108 may be a 200 OK 6042 message. AS B 108 sends an accounting request to the CDF B and the CDF B sends an acknowledgement back to AS B 108. For example, the accounting request may be an ACR 6043 and the acknowledgement may be an ACA 6044. The AS B 108 then sends the response received from user A 101 to user B 102 through the S-CSCF B 105 and the P-CSCF B 103. For example, the response sent by AS B 108 to the S-CSCF B 105 may be a 200 OK 6045 message, the response sent by the S-CSCF B 105 to the P-CSCF B 103 may be a 200 OK 6046 message and the response sent by the P-CSCF B 103 to user B 102 may be a 200 OK 6047 message. The session continues thereafter (after User B 102 sends an acknowledgement to User A 101).

[0042] FIGS. 7a, 7b, 7c and 7d are flow diagrams illustrating an example showing the charging offer-charging answer model in IMS networks, with user A 101 having online charging and user B 102 having offline charging and the session cost related information being transported. When user A 101 wishes to start a communication session with user B 102, user A 101 sends an invitation to user B 102 inviting user B 102 to join the communication session. For example, user A 101 may send an INVITE 701 message towards user B 102 to start the communication session. User A 101 can choose to have user B 102 or a third user be charged for the session. User A 101 may wish to make user B 102 as the charged party for the call, by sending the charging information in the invitation message. The invitation message may also indicate the media type that the called user would be charged for. The invitation message sent by user A 101 would be received by the AS A 108 after passing through P-CSCF A 103 and S-CSCF A 105. For example, the message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a INVITE 702 message and the message sent by the S-CSCF A 105 to AS A 108 may be a INVITE 703 message. Based on the profile of user A 101, AS A 108 may check if user A 101 is allowed to include the charging information in the invitation message. The AS A 108 checks the profile of user A 101 and/or the service logic for the session request. Since User A 101 has online charging, AS A 108 sends a credit request message towards the OCS A (shown as CM A 109 in the figure). The credit request may contain the Media-Based-Charging- Info AVP inside the IMS-Information AVP, which is, in turn, included in the Service-Information AVP. For example, the message sent by AS A 108 to the OCS A may be a CCR 704. The OCS A sends an acknowledgement back to AS A 108. The acknowledgement may be a CCA 705.

[0043] AS A 108 sends the invitation message to AS B 108 through the S-CSCF A 105, 1- CSCF B 106 and S-CSCF B 105. For example, the message sent by AS A 108 to the S-CSCF A

105 may be an INVITE 706 message, the message sent by the S-CSCF A 105 to the I-CSCF B

106 may be an INVITE 707 message, the message sent by the I-CSCF B 106 to the S-CSCF B 105 may be an INVITE 708 message and the message sent by the S-CSCF B 105 to AS B 108 may be an INVITE 709 message. The AS B 108 checks the profile of user B 102 and/or the service logic for the session request. Based on the check, the AS B 108 may determine the charging for different media types involved in the session. For example, after the check, AS B 108 may determine that the video part is free for the particular communication session. The AS B 108 includes the charging information for different media types and sends the invitation message to user B 102 through the S-CSCF B 105 and the P-CSCF B 103. For example, the message sent by AS B 108 to the S-CSCF B 105 may be an INVITE 7010 message, the message sent by the S- CSCF B 105 to the P-CSCF B 103 may be an INVITE 7011 message and the message sent by the P-CSCF B 103 to the user B 102 may be an INVITE 7012 message.

[0044] On receiving the invitation, user B 102 may choose to accept the invitation and the charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. User B 102 may also choose to have a third user, in user B's network, be charged for the session. If user B wants to have a third user be charged for the session, then user B 102 updates the charging information to indicate that a third user would be charged for the session. User B 102 also sends the identity of the third user to the network in the response message. User B 102 then sends the new charging information, towards user A 101, in a response to the invitation. For example, user B 102 may send a 200 OK 7013 response message towards user A 101 and the response message may indicate that a third user would be charged for the audio and the video would be free for the session. The response sent by user B 102 would be received by P-CSCF B 103. P-CSCF B 103 sends the response to AS B 108 through the S-CSCF B 105. For example, the response sent by the P-CSCF B 103 to the S-CSCF B 105 may be a 200 OK 7014 message and the response sent by the S-CSCF B 105 to the AS B 108 may be a 200 OK

7015 message. AS B 108 sends an accounting request to the CM B 109 and the CM B 109 sends an acknowledgement back to AS B 108. For example, the accounting request may be an ACR

7016 and the acknowledgement may be an ACA 7017. The AS B 108 then sends the response received from user B 102 to AS A 108 through the S-CSCF B 105 and the S-CSCF A 105. For example, the response sent by AS B 108 to the S-CSCF B 105 may be a 200 OK 7018 message, the response sent by the S-CSCF B 105 to the S-CSCF A 105 may be a 200 OK 7019 message and the response sent by the S-CSCF A 105 to AS A 108 may be a 200 OK 7020 message. AS A 108 sends a credit request update message to the OCS A. The credit request update message may include the Media-Based-Charging-Info AVP as a part of the IMS-Information AVP. The OCS A sends an acknowledgement to AS A 108. For example, the updated credit request may be a CCR 7021 message and the acknowledgement may be a CCA 7022 message. The AS A 108 then sends the response received from user B 102 to user A 101 through the S-CSCF A 105 and the P-CSCF A 103. For example, the message sent by AS A 108 to the S-CSCF A 105 may be a 200 OK 7023 message, the message sent by the S-CSCF A 105 to the P-CSCF A 103 may be a 200 OK 7024 message and the message sent by the P-CSCF A 103 to user A 101 may be a 200 OK 7025 message.

[0045] The communication session continues after user A 101 sends an acknowledgement to user B 102. User A 101, updates the charging information and sends a re-invitation message towards user B 102. User A 101 may also request for the session cost related information in the re- invitation message. For example, the re- invitation message sent by user A 101 may be a RE- INVITE 7026 and the session cost related information may be requested as "Session-cost-related- information-requested: Yes". The request for the cost related information is also included in the re-invitation message. The re-invitation message would be received by P-CSCF A 103 and P- CSCF A 103 sends the re-invitation message to AS A 108 through the S-CSCF A 105. For example, the re- invitation message sent by the P-CSCF A 103 to the S-CSCF A 105 may be a RE- INVITE 7027 message and the re- invitation message sent by the S-CSCF A 105 to AS A 108 may be a RE-INVITE 7028 message. AS A 108 sends a credit request update message to the OCS A. The credit request update message may include the Media-Based-Charging-Info AVP as a part of the IMS-Information AVP. The OCS A sends an acknowledgement to AS A 108. For example, the updated credit request may be a CCR 7029 message and the acknowledgement may be a CCA 7030 message. The AS A 108 then sends the re-invitation message to user B 102 through the S- CSCF A 105, CSCF B 105, AS B 108 and P-CSCF B 103. For example, the re-invitation message sent by AS A 108 to the S-CSCF A 105 may be a RE-INVITE 7031 message, the re-invitation message sent by the S-CSCF A 105 to the S-CSCF B 105 may be a RE-INVITE 7032 message, the re-invitation message sent by the S-CSCF B 105 to AS B 108 may be a RE-INVITE 7033 message, the re- invitation message sent by AS B 108 back to the S-CSCF B 105 may be a RE- INVITE 7034 message, the re-invitation message sent by the S-CSCF B 105 to P-CSCF B 103 may be a RE-INVITE 7035 message and the re- invitation message sent by the P-CSCF B 103 to user B 102 may be a RE-INVITE 7036 message.

[0046] User B 102 may choose to accept the invitation and the new charging offer or reject the invitation. If user B 102 accepts the invitation, then user B 102 sends a positive response towards user A 101. For example, user B 102 may send a 200 OK 7037 response message towards user A 101. The response would also include the new charging information. The response would be received by the P-CSCF B 103 and the P-CSCF B 103 sends the response to AS B 108 through the S-CSCF B 105. For example, the response sent by the P-CSCF B 103 to the S-CSCF B 105 may be a 200 OK 7038 message and the response sent by the S-CSCF B 105 to AS B 108 may be a 200 OK 7039 message. AS B 108 sends an accounting request to the CDF B and the CDF B sends an acknowledgement back to AS B 108. For example, the accounting request may be an ACR 7040 message and the acknowledgement may be an ACA 7041 message. AS B 108 includes the session cost related information in the response received from user B 102 and then sends the response towards user A 101 through the S-CSCF B 105, S-CSCF A 105, AS A 108 and P-CSCF B 103. For example, the session cost related information may be included in the application/sdp, ci body and the response sent by AS B 108 to the S-CSCF B 105 may be a 200 OK 7042 message, the response sent by S-CSCF B 105 to the S-CSCF A 105 may be a 200 OK 7043 message, the response sent by S-CSCF A 105 to AS A 108 may be a 200 OK 7044 message, the response sent by AS A 108 back to S-CSCF A 105 may be a 200 OK 7045 message, the response sent by S- CSCF A 105 to P-CSCF A 103 may be a 200 OK 7046 message and the response sent by P-CSCF A 103 to user A 101 may be a 200 OK 7047 message. The session continues thereafter (after User A 101 sends an acknowledgement to User B 102).

[0047] In other embodiments, the AS A 108 (or AS B 108) may send the CCR towards the

OCS if User A 101 (or User B 102) is an online charged user, after the response from User B 102 is received. In other words, the CCR may be sent after reception of the response message from User B 102, which may include the charging answer in case of charging offer-answer model, instead of sending the CCR as soon as the charging offer is initiated.

[0048] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 1 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0049] The embodiment disclosed herein specifies a system and method for allowing a third user to be charged for a communication session between the calling user and the called user. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another coding language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof, e.g. one processor and two FPGAs. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.

[0050] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

Claims

1. A method for charging users for a communication session in IMS networks, said method comprising steps of:

a first user or a second user informing said network to charge at least one other user for said communication session between said first user and said second user, for certain or all media types involved in said communication session between said first user and said second user;

said first user and said second user communicating with each other; and

said network charging at least one of said other user for said communication session, for certain or all media types involved in said communication session.

2. The method, as claimed in claim 1, said method further comprising of:

said first user or said second user requesting for session cost related information from said IMS network;

said first user or said second user obtaining said session cost related information from said IMS network; and

said first user or said second user deciding to engage in said communication session based on said session cost related information.

3. The method, as claimed in claim 1, said method further comprising said first user or said second user informing said network to charge at least one of said other user for said communication session using charging information in Session Initiation Protocol (SIP).

4. The method, as claimed in claim 3, said method further comprising said first user or said second user informing said network to charge at least one of said other user for said communication session by indicating charging indicator as "other" in said charging information.

5. The method, as claimed in claim 4, wherein said charging indicator can be indicated as "other" in at least one of:

INVITE message;

RE-INVITE message;

UPDATE message;

18x response message;

200 OK message; and

ACK message.

6. The method, as claimed in claim 1, said method further comprising said first user or said second user sends identity of at least one of said other user to said IMS network along with said charging information.

7. The method, as claimed in claim 6, said method further comprising said first user or said second user sends said identity of at least one of said other user to said IMS network before initiating said communication session.

8. The method, as claimed in claim 6, said method further comprising first user or second user sends said identity of at least one of said other user to said IMS network during said communication session.

9. The method, as claimed in claim 1 , said method further comprising session cost related information is sent in P-Charge-Info header in Session Initiation Protocol.

10. A system for charging users for a communication session in IMS networks, said system having at least one means adapted for:

informing said network, by a first user or a second user, to charge at least one other user for said communication session between said first user and said second user, for certain or all media types involved in said communication session between said first user and said second user;

enabling a communication session between said first user and said second user; and charging at least one of said other user for said communication session, for certain or all media types involved in said communication session.

11. The system, as claimed in claim 10, wherein said system is further adapted for:

requesting for session cost related information from said IMS network by said first user or said second user;

obtaining said session cost related information from said IMS network by said first user or said second user; and

enabling said first user or said second user to decide to engage in said communication session based on said session cost related information.

12. The system, as claimed in claim 10, wherein said system is further adapted to enable said first user or said second user to inform said network to charge at least one of said other user for said communication session using charging information in Session Initiation Protocol (SIP).

13. The system, as claimed in claim 10, wherein said system is further adapted to enable said first user or said second user to send an identity of at least one of said other user to said IMS network along with said charging information.

14. The system, as claimed in claim 10, wherein said system is further adapted to enable said first user or said second user to inform said network to charge at least one of said other user for said communication session by indicating charging indicator as "other" in said charging information.

15. The system, as claimed in claim 10, wherein said system is further adapted to enable a charging indicator to be indicated as "other" in at least one of:

INVITE message;

RE-INVITE message;

UPDATE message;

18x response message;

200 message; and

ACK message.