WO2011086404A1

WO2011086404A1 - Message display in ims networks

Info

Publication number: WO2011086404A1
Application number: PCT/IB2010/000601
Authority: WO
Inventors: Jayakumar Balaji; Balasubramanian Gopalasubramanian; Nainar Mahalakshmi
Original assignee: Alcatel Lucent
Priority date: 2010-01-18
Filing date: 2010-01-18
Publication date: 2011-07-21

Abstract

Message Display in IMS Networks. The present invention relates to IMS networks and, more particularly, to display of messages in IMS networks. A method and system for displaying messages to a user in an IMS network. A Softswitch obtains a message, maps the message into a format displayable to the user and sends the message to the user. The Softswitch sends a request to a Media Server (MS), requesting for the message and the MS sends the requested message to the Softswitch, The Softswitch can also obtain the message from a memory.

Description

Message Display in IMS Networks

TECHNICAL FIELD

[001] The present invention relates to IMS networks and, more particularly, to display of messages in IMS networks.

BACKGROUND

[002] When a user activates or deactivates a supplementary service or a feature, a message is conveyed to the user to indicate that the supplementary service or feature has been activated or deactivated. In an IMS network, an audio message is sent to the user to indicate that the supplementary service or feature has been activated or deactivated. For example, if a user wants to activate Call forwarding busy feature, then after the feature is activated in the IMS network, and an audio message is played to the user indicating that the call forwarding feature has been activated.

[003] If there is some disturbance in the communication link while the audio message is being played, then the user may not be able to hear the audio message. The user would thus not be aware of the activation or deactivation of the requested service or feature. Also, if there is some external noise or disturbance while the audio message is being played, the user would not be able to hear the audio message and grasp the information that was intended to be conveyed to the user.

[004] Sometimes there may be a random delay in activating or deactivating the requested service or feature. The user would, then, not receive the activation or deactivation message immediately after sending the request. Once the activation or deactivation is complete, the audio message would be played to the user. If the user is not in possession of the communication terminal while the audio message is being played, then the user would not be aware of the activation or deactivation of the requested service or feat

SUMMARY

[005] In view of the foregoing, an embodiment herein provides a method for displaying messages to a user in an IMS network. A Softswitch obtains at least one message, maps the at least one message into a format displayable to the user and sends the at least one message to the user. The Softswitch sends a request to a Media Server (MS), requesting for the at least one message and the MS sends the at least one message to the Softswitch. The Softswitch sends the request on receiving a service activation or deactivation request from the user. The request includes at least one Uniform Resource Locator (URL) for corresponding the at least one message. The Softswitch obtains at least one message from a memory, where the message is at least one of a text message, an audio message, a picture message and a video message.

[006] Embodiments further disclose a Softswitch for sending messages to a user in an IMS network. The Softswitch comprising obtains at least one message, maps the message into a format displayable to the user and sends the message to the user. The Softswitch sends a request to a Media Server (MS), requesting for the message and the MS sends the message to the Softswitch. The Softswitch includes at least one Uniform Resource Locator (URL) corresponding to each message. The Softswitch is adapted to store an announcement ID for the request, wherein the announcement ID is linked to the at least one URL. The Softswitch is adapted to obtain the at least one message from a memory.

[007] Embodiments herein also disclose a Media Server (MS) for sending messages to be displayed to a user in an IMS network. The MS receives a request from a Softswitch for at least one message and sends the requested message to the Softswitch. The MS is adapted to store the message in a memory. The MS is adapted to send the message in Session Initiation Protocol (SIP) INFO method through Content type as Media Server Control Interactive Voice Response (MSCIVR) or MSCML (Media Server Control Markup Language).

[008] 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

[009] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:

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

[0011] FIG. 2 illustrates a block diagram of a Softswitch, according to an embodiment herein;

[0012] FIG. 3 illustrates a block diagram of a Media Server (MS), according to an embodiment herein;

[0013] FIG. 4 is a flow diagram depicting the process of sending text and audio messages to the user from the media server, according to an embodiment

[0014] FIG. 5 is a flowchart depicting a method for sending text and audio messages to the user from the media server, according to an embodiment herein;

[0015] FIG. 6 is a flow diagram depicting the process of sending text message from the Softswitch and video message from the media server, according to an embodiment herein; and

[0016] FIG. 7 is a flowchart depicting a method for sending text message from the softswitch and video message from the media server, according to an embodiment herein.

DETAILED DESCRIPTION OF EMBODIMENTS

[0017] 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.

[0018] The embodiments herein disclose methods and system to simultaneously send at least a text message to a user indicating that a service or feature has been activated or deactivated, on request from the user. 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.

[0019] FIG. 1 illustrates a block diagram of an IMS network. IP Multimedia Subsystem (IMS) is an architectural framework that delivers Internet Protocol (IP) multimedia services to users. An IMS user may be a Session Initiation Protocol (SEP) user A 104, an Integrated Services Digital Network (ISDN) user B 105 or a Digital Subscriber Signaling System No. 1 (DSS1) user. A softswitch 102 in an IMS network connects different users in the network so that a session may be established between at least two of the users and users can communicate with each other or transfer information. The Softswitch 102 also provides communication call related features such as call forwarding, call waiting and last call return. The ISDN user B 105 is connected to the Softswitch 102 through a gateway 103. The gateway 103 maps protocols between different types of networks. The gateway 103 accepts a data packet formatted using a protocol and converts it to a data packet formatted using a second protocol. A Media Server (MS) 101 stores and shares media with the users of the network. The different kinds of media stored in the media server 101 may be video, audio, text or pictures. Access to the media is then made available from a central location to users. The users can also access the media from remote locations through the network.

[0020] A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the service, the user can send an activation request or deactivation request to the Softswitch 102. For example, SIP user A 104 may want to activate call waiting service and to activate the service, SIP user A 104 would send the service activation code to the Softswitch 102. The service code sent may be a message of the format 'ACT CW and the code may be sent using a mobile phone. On receiving the request, the Softswitch 102 processes the request, determines the request is intended for activating or deactivating a service or feature and activates or deactivates the feature or service for the requesting user. After activating the feature, the Softswitch 102 requests the media server 101, for the message that is to be conveyed to the user, where the message indicates to the user that the service or feature has been activated or disactivated. The media server 101 obtains the message from a memory and sends the message to the Softswitch 102. The message sent to the Softswitch 102 may be a text message or an audio message or a message with text and audio content. The text message may be a fixed text message or a variable text message and the audio may be fixed audio message or a variable audio message. A fixed message is a particular message conveyed to a user to convey particular information in general terms. A variable message may vary according to the requirement of the user and may also be a customized message that a user customizes according to the needs of the user. For example, a variable message may comprise of the name of the user. The Softswitch 102 sends the message to be displayed or played to the requesting user. For example, to convey the activation of call waiting feature to the requesting user, the fixed text message sent to the user may be: "CW feature is active" and the fixed audio message sent to the user may be: "Call waiting feature activated". A fixed message can also be said to be a "standard" message that is conveyed to a user to convey particular information. If the user needs more explicit information to be conveyed, then a variable message may be played to the user. For example, to convey the activation of call waiting feature to the requesting user, the variable text message sent to the user may be: "Call waiting feature has been active from today" and the fixed audio message sent to the user may be: "Call waiting feature has been activated from today". The variable message sent to convey any information may vary from user to user.

[0021] A variable text display can convey variable information using various media resources. A variable text message may have multiple types of data and each type of data has values. The type of data specifies the data type to be displayed and the value specifies the information conveyed using the data type. For example, types of data may be date, time, digits, price, alphabets or alphanumeric and for a data type as date, the value may be 15^th November 2004, for a data type as time, the value may be 09:00 A.M. A text display could also vary according to the name of the calling user or the called user. For example, if Mr. Joseph receives a call then the text message displayed to Mr. Joseph may be "Good Day Mr. Joseph". A variable audio announcement can also convey variable information using various media resources. A variable audio message may have multiple types of data and each type of data has values. The type of data specifies the data type to be announced and the value specifies the information conveyed using the data type. For example, the data types may be date, digit, duration, month, price, number, silence, string, time and weekday. The type of data may also have a subtype, wherein the subtype may specify a format for announcing the type of data. For example, for a type of data as date, the subtype may be "MMDDYYYY" and for a type of data as time, the subtype may determine if the time has to be announced in 12 hour format or as 24 hour format. The audio announcement may be verbal announcements or certain tones may be played to the user. For example, a tones played to the user may be music on hold tone and special information tone.

[0022] FIG. 2 illustrates a block diagram of a Softswitch. A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the service, the user sends an activation or deactivation request to the Softswitch 102. On receiving the request, the Softswitch 102 processes the request, determines the request is intended for activating or deactivating a service or feature and performs an action according to the received request. After performing the action, the Softswitch 102 requests the media server 101 for the message that is to be conveyed to the user. The Softswitch 102 requests for a text message and an audio message by including an URL for both a text message and an audio message in the request. The Softswitch 102 maintains the announcement ID in a memory 204 for the text URL and the audio URL. For example, the Softswitch 102 may sent a request to the media server 101 requesting for a text message and an audio message by including the text URL as file://CW.dat and the audio URL as file://CW.wav. The Softswitch would maintain an announcement ID for the text URL and the audio URL as:

Announcement ID: 1

Audio URL: file://CW.wav

Text URL: file://CW.dat

The media server 101 obtains the message from the memory 204 and sends the message to the Softswitch 102. The message sent to the Softswitch 102 from the SIP interface module 201 may be a text message or an audio message or a message with a combination of text and audio content. If the Softswitch 102 is unable to perform the action according to the received request, then the Softswitch 102 sends a message to the user, informing the user of the failure to perform the action. A SIP interface module 201 converts the received message into a format that can be sent to the requesting user and maps the message in a response sent to the user. For example, if the text message from the media server 101 is received in SIP INFO method with content type MSCIVR (Media Server Control Interactive Voice Response) or MSCML (Media Server Control Markup Language) format, then the SIP interface module 201 converts the received message into a SIP INFO string format by including the ASCII characters of the text in the response sent to the user. In a second example, the message received from the media server 101 may be mapped by the SIP interface module 201 into a multimedia format such as *.dat, *.avi, *.mp4, *.mp3 or any other multimedia format. In another embodiment, the text message to be sent to the user may be sent directly from the SIP interface module 201. The SIP interface module 201 may obtain the text message from the memory 204 and send the text message to the user. Here, the audio message would be obtained from the media server 101 and the text message is provided by the SIP interface module 201. For example, if the text message to be conveyed to the user is: "CF activated" and the audio message to be played to the user is: "CF service is activated", then the text message is obtained from the SIP interface module 201 and the audio message is obtained from the media server 101. On sending the mcssH^c succcs sfully to the user, the Softswitch 102 sends an acknowledgement to the MS 101. A media gateway 203 connects different types of digital media stream together to create an end-to-end path for the media in a communication session between users. The media may be text, voice or any data. A call agent 202 manages various functions and features offered to users. For example, the functions performed by the Softswitch 102 may be billing, call routing, signaling and other call related services. The call agent 202 can be said to be the "brain" of the Softswitch 102. The call agent 202 instructs the media gateway 203 to connect different media streams between different kinds of networks so that a communication session can be transparently established between users.

[0023] FIG. 3 illustrates a block diagram of a Media Server (MS). A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the sendee, the user sends a request to the Softswitch 102. After activating the feature the Softswitch 102 requests the MS 101 for the message that is to be conveyed to the user. The Softswitch 102 requests for a text message and an audio message by including an URL for both a text message and an audio message in the request. In another embodiment, the Softswitch 102 may request only for the audio message. The request is received from the Softswitch 102 using a network interface 303. The network interface 303 helps the MS 101 send and receive data from other network elements. A SIP interface module 301 in the MS 101 obtains the message from a memory 304 and sends the message to the Softswitch 102. The MS 101 stores the text message at the text URL received from the Softswitch 102. For example, if the text to be displayed is "ACTIVE" for call waiting service, then the text may be stored in hexadecimal format in CF.dat. The SIP interface module 301 fetches the stored information from the memory 304 and packs the message in the response sent to the Softswitch 102. For example, if the text message to be displayed is "ACTIVE" then the ASCII value of all letters in the word "ACTIVE" is included in the response sent to the Softswitch 102. The response is sent to the Softswitch 102 using the network interface 303. After sending the response, the MS 101, then sends a message to the Softswitch 102 to indicate the duration until which the audio message is to be played. A processor 302 controls the operation of the MS 101.

[0024] FIG. 4 is a flow diagram depicting the process of sending text and video messages to the user. A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the service, the user sends an activation or deactivation request to the Softswitch 102. For example, the activation or deactivation request may be sent as a Request message 401 by SIP user A 104. On receiving the request, the Softswitch 102 processes the request, determines if the request is intended for activating or deactivating a service or feature and activates or deactivates the service or feature for the requesting user. After activating the feature, the Softswitch 102 requests the media server 101 for the message that is to be conveyed to the user. Before requesting the MS 101, the Softswitch 102 establishes a communication session with the MS 101. The Softswitch 102 sends an invitation message inviting the MS 101 to the communication session. For example, the invitation message sent to the MS 101 may be an INVITE 402 message in the Session Description Protocol (SDP) header. On receiving the invitation from the Softswitch 102, the MS 101 sends a message to the Softswitch 102 indicating that the MS 101 is processing the invitation. For example, the message sent from the MS 101 to the Softswitch 102 may be the 100 Trying 403 message. On processing the invitation successfully, the MS 101 sends a message to the Softswitch 102 indicating the successful processing of the invitation. For example, the message sent from the Softswitch 102 to the MS 101 may be the 200 OK 404 message. The Softswitch 102 then requests the MS 101 for the message to be displayed to the user. The Softswitch 102 requests for a text message and an audio message by including a URL for both a text message and an audio message in the request. The Softswitch 102 maintains the announcement ID in a memory 204 for the text URL and the audio URL. For example, the request for the message may be sent to the MS 101 as a Request 405 message. On processing the request successfully, the MS 101 sends an acknowledgement to the Softswitch 102 indicating the successful processing of the request. The Softswitch 102 then sends the acknowledgement to the user. For example, the acknowledgement sent from the MS 101 to the Softswitch 102 may be the 200 OK 406 message and the acknowledgement sent to the SIP user A 104 may be the 200 OK 407 message.

[0025] The media server 101 then obtains the message from the memory 204 and sends the message to the Softswitch 102. The MS 101 stores the text message at the text URL received from the Softswitch 102. The message sent to the Softswitch 102 may be a text message or an audio message or a message with a combination of text and audio content. The SIP interface module 301 fetches the stored information from the memory 304 and packs the message in the response sent to the Softswitch 102. For example, the Message 408 may be sent as a MSCIVR message through SIP INFO method. The text message may be sent through SIP INFO method and the audio message may be sent through Real-Time Protocol (RTP)/MediaStream. The SIP interface module 201 in the Softswitch 102 converts the received message into a format that can be sent to the requesting user and maps the message to a response to be sent to the user. For example, if the message received from MS 101 is in the form of a SEP INFO-MSCIVR, then the SEP interface module 201 converts the message into a SIP INFO-STRING. The STRING may be the ASCII characters of the text to be displayed. In a second example, if the message is to be displayed to an ISDN User Part (ISUP) user, then the message would be converted into a parameter in the Answer (ANM) message. The Softswitch 102 then sends the Message 409 to the user. On sending the message successfully to the user, the Softswitch 102 sends an acknowledgement to the MS 101. For example, the acknowledgement sent to the MS 101 from the Softswitch 102 may be the 200 OK 4010 message.

[0026] The MS 101 then sends a message to the Softswitch 102 to indicate the duration until which the audio message is to be played. The Softswitch sends an acknowledgement to the MS 101 indicating the reception of the duration message. For example, the message sent by the MS 101 to indicate the duration of the audio message may be an End audio message 6011 and the acknowledgement sent to the MS 101 from the Softswitch 102 may be the 200 OK 4012 message. Then, the session established between the Softswitch 102 and the MS 101 is terminated. For example, the MS 101 sends a Bye 4013 message to the Softswitch 102 to terminate the session and the Softswitch 102 sends a Bye 4014 message to the user to indicate the termination of the SEP session.

[0027] FIG. 5 is a flowchart depicting a method for sending text and video messages to the user from the media server. A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the service, the user sends (501) an activation or deactivation request to the Softswitch 102. On receiving the request, the Softswitch 102 processes (502) the request, determines the request is intended for activating or deactivating a service or feature and activates or deactivates the service or feature for the requesting user. After activating the feature the Softswitch 102 conveys the service activation or deactivation message to the requesting user. The Softswitch 102 requests (503) the MS 101, for the message that is to be displayed to the user. The Softswitch 102 requests for a text message and an audio message by including an URL for both a text message and an audio message in the request. The Softswitch 102 maintains the announcement ID in a memory 204 for the text URL and the audio URL.

[0028] The MS 101 fetches (504) the stored audio URL information from 304 and sends (505) the message to the Softswitch 102. The MS 101 stores the text message at the text URL received from the Softswitch 102. The SIP interface module 301 fetches the stored information from the memory 304 and packs the message in the response sent to the Softswitch 102. The message sent to the Softswitch 102 may be a text message or an audio message or a message with a combination of text and audio content. The Softswitch 102 converts the received message into a format that can be sent to the requesting user and maps (506) the message to a response to be sent to the user. The Softswitch 102 then sends the message to the user. The MS 101, sends (507) a message to the Softswitch 102 to indicate the duration until which the audio message is to be played. Then, the session established between the Softswitch 102, the MS 101 and the user may be terminated. The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.

[0029] FIG. 6 is a flow diagram depicting the process of sending text message from the Softswitch and video message from the media server. A user may want to activate or deactivate any supplementary services or feature made available by the network at any point in time. To activate or deactivate the service, the user sends an activation or deactivation request to the Softswitch 102. For example, the activation or deactivation request may be sent as a Request message 601 by SIP user A 104. On receiving the request, the Softswitch 102 processes the request, determines if the request is intended for activating or deactivating a service or feature and activates or deactivates the service or feature for the requesting user. After activating the feature, the Softswitch 102 requests the MS 101, for the video message that is to be conveyed to the user. Before requesting the MS 101, the Softswitch 102 establishes a communication session with the MS 101. The Softswitch 102 sends an invitation message inviting the MS 101 to the communication session. For example, the invitation message sent to the MS 101 may be an INVITE 602 message in the Session Description Protocol (SDP) header. On receiving the invitation, from the Softswitch 102, the MS 101 sends a message to the Softswitch 102 indicating that the MS 101 is processing the invitation. For example, the message sent from the MS 101 to the Softswitch 102 may be the 100 Trying 603 message. On processing the invitation successfully, the MS 101 sends a message to the Softswitch 102 indicating the successful processing of the invitation. For example, the message sent from the Softswitch 102 to the MS 101 may be the 200 OK 604 message. The Softswitch 102 then requests the MS 101 for the message to be displayed to the user. The Softswitch 102 requests for a video message by including a URL for the video message in the request. The Softswitch 102 maintains the announcement ID in a memory 204 for the video URL. For example, the request for the message may be sent to the MS 101 is a Request 605 message. On processing the request successfully, the MS 101 sends an acknowledgement to the Softswitch 102 indicating the successful processing of the request. The Softswitch 102 then sends the acknowledgement to the user. For example, the acknowledgement sent from the MS 101 to the Softswitch 102 may be the 200 OK 606 message and the acknowledgement sent to the SIP user A 104 may be the 200 OK 607 message.

[0030] The MS 101 then fetches the stored information from the memory 204, packs the video message in the response sent to the Softswitch 102 and sends the video message as RTP/MediaStreams to the Softswitch 102. For example, the video message may be sent as a Message 608. The text message to be sent to the user is sent directly from the Softswitch 102. The SIP interface module 201 obtains the text message from the memory 204 and the text message is sent to the user. The SIP interface module 201 in the Softswitch 102 converts the text message into a format that can be sent to the requesting user and maps the message to a response to be sent to the user. The Softswitch 102 then sends the Message 609 to the user. On receiving the message successfully, the user sends an acknowledgement to the MS 101. For example, the acknowledgement sent to the Softswitch 102 from the user may be the 200 OK 6010 message.

[0031] The MS 101 then sends a message to the Softswitch 102 to indicate the duration until which the video message is to be played. The Softswitch sends an acknowledgement to the MS 101 indicating the reception of the duration message. For example, the message sent by the MS 101 to indicate the duration of the video message may be an End video message 6011 and the acknowledgement sent to the MS 101 from the Softswitch 102 may be the 200 OK 6012 message. Then, the session established between the Softswitch 102 and the MS 101 is terminated. For example, the MS 101 sends a Bye 6013 message to the Softswitch 102 to terminate the session and the Softswitch 102 sends a Bye 6014 message to the user to indicate the termination of the SIP session.

[0032] FIG. 7 is a flowchart depicting a method for sending text message from the Softswitch and video message from the media server. A user may want to activate or deactivate any service or feature made available by the network at any point in time. To activate or deactivate the service, the user sends (701) an activation or deactivation request to the Softswitch 102. On receiving the request, the Softswitch 102 processes (702) the request, determines the request is intended for activating or deactivating a service or feature and activates or deactivates the service or feature for the requesting user. After activating the feature the Softswitch 102 requests (703) the media server 101 for the video message that is to be conveyed to the user. The Softswitch 102 requests for a video message by including a URL for the video message in the request. The Softswitch 102 maintains the announcement ID in a memory 204 for the video URL.

[0033] The media server 101 fetches (704) the stored Video URL from the memory 304, packs the video message in the response sent to the Softswitch 102 and sends (705) the video message to the Softswitch 102. The text message to be sent to the user is sent directly from the Softswitch 102. The SIP interface module 201 obtains the text message from the memory 204 and the text message is sent (706) to the user. The SIP interface module 201 in the Softswitch 102 converts the text message and video message into a format that can be sent to the requesting user and maps the message to a response to be sent to the user. The Softswitch 102 sends (707) the message to the user. The MS 101, then sends (708) a message to the Softswitch 102 to indicate the duration until which the video message is to be played. Then, the session established between the Softswitch 102, the MS 101 and the user is terminated. The various actions in method 700 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 7 may be omitted.

[0034] The messages sent to the user are used to convey information to the user. The messages sent to the user may be text messages or audio messages or special information tone or a message with a combination of text, audio content and special information tone. The text and audio messages may be played simultaneously. Also, the text and audio messages may be played one after another. The text message may be fixed or variable and the audio message may also be fixed or variable. Text messages are sent between the Softswitch 102 and a DSSl user in the SIP network in the method used to send text messages to DSSl users in any Integrate Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN). In other embodiments video messages, picture messages or any other kind of data may also be sent to the user to convey information. In another embodiment an application server or a Intelligent Network Application Part (INAP) server such as an Open System Platform (OSP) server may be included between the MS 101 and softswtich 102 to send messages to the user.

[0035] 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 , Fig. 2 and Fig. 3 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.

[0036] The embodiment disclosed herein specifies methods and system for displaying text and audio messages to the user. The mechanism allows information to be conveyed to the user by having text and audio messages displayed to the user providing a system thereof. 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.

[0037] 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

C L LTJT I S What is claimed is:

1. A method for displaying messages to a user in an IMS network, said method comprising steps of a Softswitch obtaining at least one message;

said Softswitch mapping said at least one message into a format displayable to said user; and

said Softswitch sending said at least one message to said user,

2. The method, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said method comprising steps of said Softswitch sending a request to a Media Server (MS), requesting for said at least one message; and

said MS sending said at least one message to said Softswitch.

3. The method, as claimed in claim 2, wherein said Softswitch sends said request on receiving a service activation or deactivation request from said user.

4. The method, as claimed in claim 2, wherein said request includes at least one Uniform Resource Locator (URL) for corresponding said at least one message

5. The method, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said Softswitch obtains said at least one message from a memory.

6. The method, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said at least one message is at least one of a text message;

an audio message;

a picture message; and

a video message.

7. A softswitch for sending messages to a user in an IMS network, said softswitch comprising at least one means adapted for

obtaining at least one message; mapping said at least one message into a format displayable to said user; and sending said at least one message to said user.

8. The softswitch, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said softswitch is adapted to

send a request to a Media Server (MS), requesting for said at least one message; and said MS sending said at least one message to said softswitch.

9. The softswitch, as claimed in claim [006] , wherein said softswitch is adapted to include at least one Uniform Resource Locator (URL) for corresponding said at least one message.

10. The softswitch, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said softswitch is adapted to store an announcement ID for said request, wherein said announcement ID is linked to said at least one URL.

11. The Softswitch, as claimed in claim Erreur ! Source du renvoi introuvable., wherein said Softswitch is adapted to obtain said at least one message from a memory.

12. A Media Server (MS) for sending messages to be displayed to a user in an IMS network, said MS comprising at least one means adapted for receiving a request from a Softswitch, wherein said request requests for at least one message; and

sending said at least one message to said Softswitch.

13. The MS, as claimed in claim 12, wherein said MS is adapted to store said at least one message in a memory.

14. The MS, as claimed in claim 12, wherein said Softswitch is adapted to send said at least one message using atleast one of

Session Initiation Protocol (SIP) INFO-Media Server Control Interactive Voice Response (MSCIVR); and

Session Initiation Protocol (SEP) INFO-MSCML (Media Server Control Markup Language).