WO2007004933A1

WO2007004933A1 - A method and arrangement for setting up a packet-switched communication session

Info

Publication number: WO2007004933A1
Application number: PCT/SE2005/001084
Authority: WO
Inventors: Robert Skog
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2005-07-01
Filing date: 2005-07-01
Publication date: 2007-01-11
Also published as: KR20080031926A; KR101177601B1; EP1900183A1; EP1900183A4; CN101213823A; MX2007015971A

Abstract

A method and arrangement for providing a personalised call greeting to an opposite second communication terminal (A) during a setup procedure for a packet-switched multimedia session. The opposite terminal is first identified, and then a file identity associated with the calling terminal and containing said call greeting is retrieved (3:2). The file identity is sent (3:3) to the opposite terminal, wherein the opposite terminal can playout a corresponding file as said call greeting if the file has been stored therein previously.

Description

A METHOD AND ARRANGEMENT FOR SETTING UP A PACKET-SWITCHED COMMUNICATION SESSION.

TECHNICAL FIELD The present invention relates generally to a method and arrangement for providing a selective ring-back or ringing function when setting up a packet-switched communication session. In particular, the invention provides a novel solution for using selected media content to generate a "greeting" either in a ring-back or a ringing signal, while waiting for an answer during the call-setup procedure.

BACKGROUND OF THE INVENTION AND PRIOR ART With the emergence of 3G mobile telephony, new packet-based communication technologies have been developed to support multimedia communication. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video files, etc., in addition to traditional circuit-switched voice calls.

Multimedia services typically involve transmission of encoded data representing text, documents, images, audio files and video files in different formats and combinations. The term "multimedia" will be used in this description as generally referring to any choice of media types, apart from ordinary voice dialogues, and typically with some visual content, which is communicated by using the packet based IP (Internet Protocol) transport technology. Further, the term "media content" will be used to represent any such encoded data used when exercising multimedia services.

A network architecture called "IP Multimedia Subsystem" (IMS) has been developed by the 3^rd Generation Partnership Project (3GPP) as an open standard, to give operators of access networks the ability to offer multimedia services in the packet domain. IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used, and is basically not restricted to any limited set of specific services.

A specification for handling sessions in IMS networks has been defined called "SIP" (Session Initiation Protocol, according to the standard IETF RFC 3261) . SIP is an application-layer control (signalling) protocol for creating, modifying and terminating sessions over a packet- switched logic. The SIP standard is thus used by IMS systems and SIP-enabled terminals to establish and control IP multimedia communications. For example, a message called "invite" is defined in SIP to initiate a session during session set-up. The SIP invite message includes, among other things, information on required codec (s) and other communication parameters needed for the forthcoming session.

Fig. 1 is a simplified illustration of a basic, network structure for providing multimedia services by means of an IMS service network. A first mobile terminal A is connected to a first radio access network 100 and communicates with a second mobile terminal B connected to a second radio access network 102, in a communication session S involving one or more multimedia services. An IMS network 104 is connected to the first radio access network 100 and handles the session with respect to terminal A. In this figure, a corresponding IMS network 106 handles the session on behalf of terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Alternatively, two communicating terminals A and B may of course be connected to the same access network and/or may belong to the same IMS network.

The session S is generally managed, using SIP signalling, by specific nodes in each IMS network, here generally referred to as "session managing nodes" 108. These nodes typically include S-CSCF (Serving Call Session Control Function) , I-CSCF (Interrogating Call Session Control

Function) and P-CSCF (Proxy Call Session Control Function) . Each IMS network 104,106 also includes one or more application servers 110 for enabling various multimedia services. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things. IMS network 106 is basically similar to network 104. The various specific functions of the shown network elements 108-112 are generally known in the art, but they are not necessary to describe here further to understand the context of the present invention. Of course, the IMS networks 104,106 contain numerous other nodes and functions, which are not shown here for the sake of simplicity.

During a call-setup between a calling terminal A and a called terminal B, a simple ring-back tone is traditionally emitted at terminal A to indicate that a ringing signal has been activated at terminal B. Although any type of ringing signal can typically be pre-selected by the user of the called terminal, such as a piece of music, vibration or any recorded sound, the ring-back tone given at the calling terminal normally consists of a dull repeated tone. In circuit-switched networks, a service is available for entertaining a calling party with music while he/she is waiting for an answer from the called party, sometimes referred to as ^ΛΛmusic ring-back tone". This service is often used by telephone exchanges at authorities and enterprises where the answer can be greatly delayed, e.g. when placed in a telephone queue. A pre-recorded piece of music or information is then played to the calling party while waiting for an answer. According to conventional circuit-switched call-setup procedures, a ring-back sound or audio piece, as selected by the called party, is transferred ^λΛin-band" to the calling terminal A over a channel reserved for the call being setup.

SIP also allows for the ring-back tone as well as the ringing signal to be selected by the opposite party, for multimedia sessions in the IMS context. In both SIP messages ^Λinvite' (explained above) and ^Λ180 ringing' (a standard response message indicating ringing at B) , a header field called "Alert info" has been defined to accommodate an identity of an alternative ringing signal or ring-back tone, respectively. The intention is that the network of terminal A may add a URL (Uniform Resource Locator) or the like in that field of an ^Λinvite' message, to direct terminal B to a corresponding server for fetching a file or the like containing the indicated ringing signal. In a similar manner, the network of terminal B may add a URL in that field of a ^λ180 ringing' message, to direct terminal A to a corresponding server for fetching a file with the indicated ring-back tone. In this way, a mechanism is provided for enabling a personalised greeting feature in either direction. Fig. 2 is a simplified signalling diagram for a conventional packet-switched call-setup between a calling terminal A connected to a first IMS network 104, and a called terminal B connected to a second IMS network 106, using SIP signalling. In particular, the figure illustrates how a personalised greeting feature can be implemented according to the prior art.

In a first step 200, terminal A sends an ^λinvite' message towards terminal B to initiate a multimedia session. A suitable session managing node in IMS network 104 now has the opportunity of adding an identity of a ringing file in the above-mentioned alert info field in the ^Λinvite' message, such as a URL, as indicated in a step 202. When receiving the invite message, terminal B may use the ringing file identity URL to fetch the proposed ringing file from a corresponding server and play it as a ringing signal during the call-setup. Terminal B also responds by sending a standard ^Λ180 ringing' message towards terminal A, in a next step 204, to indicate activation of a ringing signal at terminal B.

Similar to step 202, a suitable session managing node in IMS network 106 can now add an identity of a ring- back file, such as a URL, in the above-mentioned alert info field in the ^λ180 ringing' message, as indicated in a step 206. Thus, when terminal A receives this message,- it can use the ring-back file identity URL to fetch the proposed file from a corresponding server and play it as a ring-back tone during the call-setup while waiting for an answer.

To enable any of the above-described functions, the terminal user must configure it in advance by defining subscriber preferences or the like in the corresponding IMS network. Upon call-setup, the network must then retrieve the ring-back file or ringing file identity as defined, e.g. based on the identity of the opposite party and/or other factors, in order to provide it to the opposite terminal.

However, it is a problem that the network must, for each session-setup, perform a delaying routine of determining whether a specific user-selected greeting (i.e. a ring-back tone or ringing signal) is to be provided at the opposite terminal, and adding a corresponding file identity in a session-setup message, e.g. as described above. It is also a problem that the called or calling terminal must fetch or download the indicated file from a server to enable this function each time a session is being set up, involving added consumption of precious bandwidth. This procedure may also take some time, such that the called party may well have answered before the file has been downloaded for play- out, making the whole process pointless

It is generally desirable to facilitate the feature of selectively providing a "greeting" or the like to the opposite, either calling or called, terminal user during session-setup. In particular, it is desirable to minimise the signalling and processing load required for this service. It is also desirable to minimise the time delay before the greeting can be played out.

Applicant's own Swedish patent application SE 0501419-6 describes a solution for providing a ring-back presentation to a calling terminal after receiving a call setup request for a first communication session. A second packet-based communication session is established with the calling terminal to provide pre-defined media content as said ring-back presentation to the calling terminal over the second session. SUMMARY OF THE INVENTION

It is an object of the present invention to generally avoid the problems outlined above. More specifically, it is an object of the present invention to facilitate the feature of selectively providing a call greeting to an opposite calling or called terminal during a packet-switched session-setup. Another object is to reduce the signalling and processing load required for this feature, as well as the time delay before the call greeting can be played out. Another object is to minimise the bandwidth consumption during a session-setup procedure using this feature.

These objects and others are obtained by providing a method and a communication terminal according to the independent claims attached below.

The inventive method is to be executed in a first communication terminal, for providing a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session. According to one aspect of the invention, after identifying the opposite terminal, at least one file identity is retrieved that has been predefined for the opposite terminal and refers to at least one media file containing said call greeting. Then, the retrieved file identity is sent to the opposite terminal, wherein the opposite terminal can retrieve and playout at least one corresponding file as said call greeting if the file(s) has been stored therein previously.

If the opposite terminal is a calling terminal, it may be identified by receiving a session initiating message, and when SIP signalling is used, the session initiating message is an SIP ^Λinvite' message. The retrieved file identity may then be sent to the opposite terminal embedded in a response message to the session initiating message. When using SIP signalling, the response message is an SIP ^Λ180 ringing' message. If the opposite terminal is a called terminal, it is identified when its telephone number is entered. The retrieved file identity may then be sent to the opposite terminal embedded in a session initiating message. When SIP signalling is used, the session initiating message is an SIP ^Λinvite' message.

The file identity may be sent as a URN. In an alternative embodiment, a network address of a server having the file may be sent together with the file identity as a URL or a URI, wherein the opposite terminal can fetch a corresponding file from said server for playout as said call greeting, if the file has not been stored in the opposite terminal previously. If SIP signalling is used, the URN or URL or URI can be embedded in an existing header field called ^λAlert info' in an SIP ^Λinvite' message or an SIP ^λ180 ringing' message, respectively.

The file identity may have been predefined for any unknown opposite terminal and then refers to a media file containing a default call greeting. Also, different file identities may have been defined for different potential opposite terminals, and/or depending on current date or time of day, week or season, and/or depending on a user status.

According to another aspect of the invention, after identifying the opposite terminal, a text string is retrieved associated with the calling terminal and containing said call greeting, and the retrieved text string is sent to the opposite terminal, wherein the opposite terminal can display the text string as said call greeting. The present invention further encompasses a first communication terminal adapted to provide a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session. The first communication terminal includes means for identifying the opposite terminal, means for retrieving at least one file identity that has been predefined for the opposite terminal and refers to at least one media file containing said call greeting, and means for sending the retrieved file identity to the opposite terminal, wherein the opposite terminal can retrieve and playout at least one corresponding file as said call greeting if the file(s) has been stored therein previously.

If the opposite terminal is a calling terminal, the identifying means may be adapted to identify the opposite terminal by receiving a session initiating message. When the terminal is adapted to use SIP signalling, the session initiating message is an SIP ^Λinvite' message. The sending means may be adapted to send the retrieved file identity to the opposite terminal embedded in a response message to the session initiating message. Using SIP signalling, the response message is an SIP ^λ180 ringing' message.

If the opposite terminal is a called terminal, the identifying means is adapted to identify the opposite terminal when its telephone number is entered. In that case, the sending means may be adapted to send the retrieved file identity to the opposite terminal embedded in a session initiating message. When the terminal is adapted to use SIP signalling, the session initiating message is an SIP ^invite' message.

The sending means may be adapted to send the file identity as a URN. In an alternative embodiment, the sending means may be adapted to send a network address of a server having the file together with the file identity as a URL or a URI, wherein the opposite terminal can fetch a corresponding file from said server for playout as said call greeting, if the file has not been stored in the opposite terminal previously. When the terminal is adapted to use SIP signalling, the URN or URL or URI is embedded in an existing header field called ^ΛAlert info' in an SIP ^Λinvite' message or an SIP ^λ180 ringing' message, respectively. In the inventive terminal, the file identity may have been predefined for any unknown opposite terminal and refers to a media file containing a default call greeting. Further, different file identities have been defined for different potential opposite terminals, and/or depending on the current date or time of the day, week or season, and/or depending on a user status .

The present invention further encompasses a first communication terminal having means for identifying the opposite terminal, means for retrieving a text string associated with the calling terminal and containing said call greeting, and means for sending the retrieved text string to the opposite terminal, wherein the opposite terminal can display the text string as said call greeting. Further features of the present invention and its benefits will be explained in the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means of preferred embodiments and with reference to the accompanying drawings, in which: Fig. 1 is a schematic view of a conventional network structure for communicating multimedia content . Fig. 2 is a signalling diagram illustrating a packet- switched session-setup procedure involving a personalised greeting feature, according to the prior art.

Fig. 3 is a block diagram of two terminals during a session-setup procedure involving a personalised call greeting in the manner of a ring-back tone, according to one embodiment . - Fig. 4 is a block diagram of two terminals during a session-setup procedure involving a personalised call greeting in the manner of a ringing signal, according to another embodiment. Fig. 5 is a flow chart illustrating a basic procedure for providing a personalised call greeting to an opposite terminal during a session-setup procedure, in accordance with the present invention.

Fig. 6 is a flow chart illustrating a basic procedure for receiving a personalised call greeting from an opposite terminal during a session-setup procedure, according to another embodiment.

Fig. 7 is a flow chart illustrating a basic procedure for receiving a personalised call greeting from an opposite terminal during a session-setup procedure, according to yet another embodiment .

DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, the term "call greeting" will be used to represent any type of media content presented to a user of an opposite terminal, while waiting for an answer during a session-setup procedure for a packet-switched multimedia session. Thus, a call greeting can be presented at a called terminal in the manner of a ringing signal, or at a calling terminal in the manner of a ring-back tone, although the call greeting can be composed of any visual and/or audible media type(s). For example, an image of the calling person may be displayed at the called terminal, at the same time a specific audio sequence, or a default ringing signal, is played out. Hence, the present invention is not limited to any specific media types as call greetings. In this description, the phrases ^λλin the manner of a ringing signal" and "in the manner of a ring-back tone" merely refer to the direction of the greeting.

The expression "playout" of a file is intended to represent any method of presenting a call greeting on a terminal, e.g. by playing an animation, a video clip or an audio clip, or by displaying an image or an icon, regardless of the file format used. Further, the term "a file" may refer to any number of media files making up the intended call greeting.

The present inventive solution will first be described with reference to two basic exemplary block diagrams during session-setup shown in Fig's 3 and 4, respectively. In both figures, a calling terminal A and a called terminal B are involved in a setup procedure for a packet-switched multimedia session. The basic idea is that a file identity is sent to the opposite terminal, and that the file in question has presumably already been stored therein, and can therefore be retrieved as a call greeting.-

In Fig. 3, a call greeting will be presented to the calling terminal A in the manner of a ring-back tone. A first step 3:1 illustrates that terminal A generally sends a session initiating message to terminal B, such as the above- described SIP message ^Λinvite' , by means of a schematically illustrated communication entity 304. Terminal B receives the session initiating message at a likewise schematically illustrated communication entity 300.

Terminal B then identifies the calling terminal A, as typically given in the session initiating message, and checks whether a personalised call greeting is to be presented to the user of terminal A by consulting a database 302 in terminal B. It is assumed that a user of terminal B has pre-stored a number of known potential callers in ^" database 302 together with identities of selected media files to be played out at the corresponding terminal during session setup. It is also possible to define one or more files to be used as a "default" call greeting for any unknown opposite terminal. Furthermore, different call greeting files may have been defined depending on the current date or time of the day, week or season, and/or depending on a user status.

It should be noted that the files themselves need not be stored in database 302, but only their identities in this example. A file identity may be given in any conventional manner, e.g. "name + file type" or similar. Thus, a step 3:2 generally indicates that a file identity associated with the calling terminal is retrieved from the database 302. When terminal B duly responds to the session initiating message of step 3:1 by sending a response message, e.g. the above-described SIP message ^Λ180 ringing', the retrieved file identity is added to this response message, which is then sent to terminal A in a step 3:3. To this end, the above-described header field "Alert info" in the ^Λ180 ringing' message can be utilised, if SIP signalling is used for the session setup. Thus, terminal B may insert a URN (Universal Resource Name) in that field, which is a standardised file name type, before sending the message in step 3:3. A URN is uniquely defined and may be built in the manner of e.g. "urn: song. seme. com: happysong", which can easily be accommodated in the Alert info field.

Alternatively, a terminal user may have freely defined any more or less "ordinary" name of a call greeting file that may well be non-unique, assuming that the opposite terminal has a file stored with that particular name, e.g. as received at an earlier occasion.

When terminal A receives the file identity of step 3:3, it may be able to retrieve the indicated file in a following step 3:4 from a database 306 containing various files. Generally, it is quite common that a modern terminal has a storage unit or database containing a collection of various files that a terminal user may have downloaded previously, for different reasons, or that may have been stored "by default" in connection with the manufacturing and/or configuration of the terminal. In the shown example, terminal A happens to have the indicated file stored in database 306, and can therefore easily retrieve the file therefrom and provide it to a schematically illustrated "playout" entity 308, in a step 3:5, for playout in the manner of a "ring-back tone". The playout entity 308 of terminal A may comprise any components needed for the playout of media, such as decoders, a display screen, a loudspeaker, etc.

On the other hand, it may happen that terminal A does not have the file stored. Therefore, in an alternative embodiment, terminal B may also provide a network address of a server having the file, together with the file identity in the message of step 3:3. For example, a URL (Uniform Resource Locator) or a URI (Uniform Resource Identifier) may be inserted in the above-mentioned Alert info header field, containing information on "location + name + file type", or similar. In this case, terminal A can thus fetch the file from the server, as given by the network address, and play it out, or at least store it in database 306 for playout another time when setting up a new session with terminal B. In another alternative embodiment, terminal B may provide the entire greeting as a text string accommodated in the response message of step 3:3, e.g. in the above- mentioned Alert info header field in ^Λ180 ringing' . In that case, terminal A can "play out", in this case display, the text string immediately after step 3:3, whereas steps 3:4 and 3:5 can therefore be omitted. In Fig. 4, a call greeting as selected by the user of terminal A will be presented to the user of terminal B, in the manner of a ringing signal. When the telephone number of B has been entered in terminal A, the called terminal B can be identified. It is then checked whether a personalised call greeting is to be presented when calling terminal B, by consulting a database 402 in terminal A. As in the database 302 of terminal B in Fig. 3, a number of potential callers have been pre-stored in database 402 along with identities of selected media files to be played at the corresponding terminal during session setup. Also here, one or more files may also have been defined for presenting a default call greeting in case the opposite terminal is unknown.

Thus, a first step 4:1 generally indicates that a file identity associated with the called terminal B is retrieved from the database 402. Of course, for a particular candidate opposite terminal, it is possible to pre-store one call greeting for outgoing calls (to be presented in the manner of a ringing signal) and another call greeting for incoming calls (to be presented in the manner of a ring-back tone) .

Next, in a following step 4:2, terminal A will generally send a session initiating message to terminal B, such as the above-described SIP message ^λinvite' , by means of a communication entity 400, which will be received at a corresponding communication entity 404 in terminal B. However, the file identity retrieved in step 4:1 is first added to the session initiating message, e.g. in the above- described header field "Alert info" in an ^λinvite' message if SIP signalling is used for the session setup. Similar to step 3:3 in the previous embodiment in Fig. 3, terminal A may insert a URN in that field before sending the message in step 4:2. Again, the basic idea is that the file in question may have been stored in terminal B, and in that case can be retrieved as a call greeting. If not, a URL or a URI or a 'text string may be inserted in the message instead, in a manner similar to the above exemplary alternatives that were given for Fig. 3.

When terminal B receives the file identity of step 4:2, it may be able to retrieve the indicated file in a following step 4:3 from a database 406 containing various files, just like database 306 in Fig. 3. Also in this example, terminal B happens to have the indicated file stored in database 406, and can therefore retrieve the file therefrom and provide it to a playout entity 408, in a step 4:4, for playout in the manner of a "ringing signal". The session-setup procedure itself may continue conventionally from that point, although not shown here.

Fig. 5 is a basic flow chart of a procedure, as executed in a first terminal, for providing a personalised call greeting to an opposite second terminal during a setup procedure for a packet-switched session, in accordance with the present invention. In a first step 500, the session setup is generally started, by either receiving a session initiating message (e.g. SIP ^λinvite' ) or when a telephone number is entered. In a next step 502, the opposite terminal is identified, by means of either a received session initiating message or an entered telephone number.

Thereafter in a step 504, it is determined whether a call greeting is to be provided at the opposite terminal, e.g. by checking a database such as those 302,402 described in Fig's 3 and 4, respectively. If not, a "regular" procedure takes over in a step 506, meaning that a default ringing signal or ring-back tone may be used. However, if it is determined in step 504 that a call greeting is to be provided, a call greeting file associated with the opposite terminal is selected in a step 508. More precisely, a corresponding file identity is retrieved, e.g. as in the above-described steps 3:2 and 4:1, respectively. The file identity is then sent to the opposite terminal, in a final step 510. It should be noted that the described procedure of Fig. 5 is valid both for a calling terminal providing a call greeting in the manner of a ringing signal, and for a called terminal providing a call greeting in the manner of a ring- back tone.

^• Fig. 6 is a flow chart illustrating a basic procedure, as executed in a first terminal, for receiving a personalised call greeting from an opposite second terminal during a call-setup procedure for a packet-switched session, according to another embodiment. In a first step 600, the session setup is generally started, by either receiving a session initiating message (e.g. SIP invite) from the opposite terminal, or by sending a session initiating message (e.g. SIP invite) to the opposite terminal when a telephone number has been entered. In a next step 602, a file identity is received from the opposite terminal, e.g. as a URN, which may be either embedded in a received session initiating message (e.g. SIP ^λinvite' ) , or embedded in a received response message (e.g. SIP ^λ180 ringing').

Thereafter in a step 604, it is determined whether the indicated file is stored in the terminal, e.g. by checking a database therein such as the ones 306,406 described in Fig's 3 and 4, respectively. If not, a regular procedure may again take over by a activating a default .ringing signal or ring-back tone, in a step 606. However, if it is determined in step 604 that the indicated file is actually stored in the terminal, the file can be retrieved and played out, in a final step 608. It should be noted that the described procedure of Fig. 6 is valid both for a calling terminal receiving a call greeting in the manner of a ring-back tone, and for a called terminal receiving a call greeting in the manner of a ringing signal.

Finally, an alternative procedure will be described with reference to a flow chart shown in Fig. 7, as executed in a first terminal, for receiving a personalised call greeting from an opposite second terminal during a call-setup procedure for a packet-switched session, according to yet another embodiment. In a first step 700, the session setup is generally started, as similar to step 600 in the preceding example, by either receiving a session initiating message (e.g. SIP invite) from the opposite terminal, or by sending a session initiating message (e.g.

SIP invite) to the opposite terminal when a telephone number has been entered. In a next step 702, a file identity together with location information on where the file can be fetched, is received from the opposite terminal, e.g. as a URL as described above. Again, the received file identity and location information may be either embedded in a received session initiating message (e.g. SIP ^λinvite' ) , or embedded in a received response message (e.g. SIP ^λ180 ringing' ) .

Thereafter in a step 704, it is determined whether the indicated file is stored in the terminal, e.g. by checking a database therein such as^■ the ones 306,406 described in Fig's 3 and 4, respectively. If so, the file can be retrieved and played out, in a step 706, just like step 608 in the preceding example. However, if it is determined in step 704 that the indicated file is not stored in the terminal, the indicated file can be fetched from a server by using the indicated location information, in a step 708. At the same time, a default ring-back tone or ringing signal may be activated, as indicated by an optional parallel step 710. If the terminal manage to fetch the file in due time, e.g. before the session setup is completed, the file can be played out as a call greeting in a final step 712. However, even if the session setup has been completed before obtaining the file, it is still possible to play it out as a call greeting during the ongoing session. In any case, the fetched file is preferably also stored in the terminal in step 712 for later playout another time when setting up a new session with terminal B. It should be noted that the described procedure of Fig. 7 is valid both for a calling terminal receiving a call greeting in the manner of a ring- back tone, and for a called terminal receiving a call greeting in the manner of a ringing signal. When using the present invention, e.g. according to the described embodiments, the feature of selectively providing a call greeting to an opposite calling or called terminal during a packet-switched session-setup, is facilitated considerably. In particular, the signalling and processing load required for this feature, as well as the time delay before the call greeting can be played out, is minimised since only a file identity of relatively small size is communicated. The file containing the selected call greeting is hopefully already available in the terminal where it can be immediately played out. The inventive solution can be seen as suggesting a particular call greeting by means of the indicated file, which may be accepted if it is stored in the opposite terminal. Otherwise, a default signal or tone is generated, without any extra signalling or bandwidth being wasted.

The described embodiments can be modified in several ways, within the scope of the present invention. For example, more than one file may make up the call greeting such that a plurality of file identities can be sent to the opposite terminal, to indicate playout of plural corresponding files simultaneously or in sequence.

Further, a conventional function with a default ringing signal or ring-back tone may be activated at the same time as a personalised call greeting is played out according to the present solution. For example, it may be desirable to emit a conventional ringing signal at the same time a selected image or video clip is displayed at a called terminal. It may also be desirable to emit a conventional ring-back tone at the same time a selected audio clip and/or video clip is played at a calling terminal, etc. A user may also send a particular file to another terminal, or propose downloading thereof from a server, in order to later send the file's corresponding identity during a subsequent session setup to have the file played out as a call greeting according to the present invention.

The present solution allows for selective call greetings based on the identity of the opposite terminal, such that certain pre-selected terminals may receive a specific call greeting, whereas others may not. Groups of specific potential callers may also be defined to receive different call greetings, and so forth. It is also possible to select different call greeting files depending on various time factors, such as the current date or time of the day, week or season, etc. Still further, a succession of different call greetings may be presented if the session setup is increasingly delayed. Moreover, it is also possible for the user to define different call greeting files depending on a user status, such as "busy", and even "busy: meeting", "busy: at cinema", "busy: sleeping", etc. While the invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention, which is defined by the appended claims.

Claims

1. A method, as executed in a first communication terminal, of providing a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session, characterised by the following steps:

- identifying the opposite terminal,

- retrieving at least one file identity that has been predefined for the opposite terminal and refers to at least one media file containing said call greeting, and

- sending the retrieved file identity to the opposite terminal, wherein the opposite terminal can retrieve and playout at least one corresponding file as said call greeting if the file(s) has been stored therein previously.

2. A method according to claim 1, wherein the opposite terminal is a calling terminal, characterised in that the opposite terminal is identified by receiving a session initiating message.

3. A method according to claim 2, wherein SIP signalling is used and the session initiating message is an SIP ^Λinvite' message.

4. A method according to claim 2 or 3, characterised in that the retrieved file identity is sent to the opposite terminal embedded in a response message to the session initiating message.

5. A method according to claim 3 and 4, characterised in that the response message is an SIP ^Λ180 ringing' message.

6. A method according to claim 5, wherein the opposite terminal is a called terminal, characterised in that the opposite terminal is identified when its telephone number is entered.

7. A method according to claim 6, characterised in that the retrieved file identity is sent to the opposite terminal embedded in a session initiating message.

8. A method according to claim 7, wherein SIP signalling is used and the session initiating message is an SIP ^λinvite' message.

9. A method according to any of claims 1-8, characterised in that the file identity is sent as a URN.

10. A method according to any of claims 1-8, characterised in that a network address of a server having the file is sent together with the file identity as a URL or a URI, wherein the opposite terminal can fetch a corresponding file from said server for playout as said call greeting, if the file has not been stored in the opposite terminal previously.

11. A method according to claim 9 or 10, wherein SIP signalling is used, characterised in that the URN or URL or URI is embedded in an existing header field called ^ΛAlert info' in an SIP ^Λinvite' message or an SIP ^Λ180 ringing' message, respectively.

12.A method according to any of claims 1-11, characterised in that said file identity has been predefined for any unknown opposite terminal and refers to a media file containing a default call greeting.

13.A method according to any of claims 1-12, characterised in that different file identities have been defined for different potential opposite terminals, and/or depending on the current date or time of the day, week or season, and/or depending on a user status.

14.A method, as executed in a first communication terminal, of providing a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session, characterised by the following steps: - identifying the opposite terminal,

- retrieving a text string associated with the calling terminal and containing said call greeting, and

- sending the retrieved text string to the opposite terminal, wherein the opposite terminal can display the text string as said call greeting.

15. A first communication terminal adapted to provide a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session, characterised by:

- means for identifying the opposite terminal, means for retrieving at least one file identity that has been predefined for the opposite terminal and refers to at least one media file containing said call greeting, and - means for sending the retrieved file identity to the opposite terminal, wherein the opposite terminal can retrieve and playout at least one corresponding file as said call greeting if the file(s) has been stored therein previously.

16. A terminal according to claim 15, wherein the opposite terminal is a calling terminal, characterised in that said identifying means is adapted to identify the opposite terminal by receiving a session initiating message.

17. A terminal according to claim 16, adapted to use SIP signalling wherein the session initiating message is an SIP ^Λinvite' message.

18.A terminal according to claim 16 or 17, characterised in that said sending means is adapted to send the retrieved file identity to the opposite terminal embedded in a response message to the session initiating message.

19.A terminal according to claim 17 and 18, characterised in that the response message is an SIP ^Λ180 ringing' message.

20. A terminal according to claim 19, wherein the opposite terminal is a called terminal, characterised in that said identifying means is adapted to identify the opposite terminal when its telephone number is entered.

21.A terminal according to claim 20, characterised in that said sending means is adapted to send the retrieved file identity to the opposite terminal embedded in a session initiating message.

22.A terminal according to claim 21, adapted to use SIP signalling wherein the session initiating message is an SIP ^λinvite' message.

23.A terminal according to any of claims 15-22, characterised in that said sending means is adapted to send the file identity as a URN.

24.A terminal according to any of claims 15-22, characterised in that said sending means is adapted to send a network address of a server having the file together with the file identity as a URL or a URI, wherein the opposite terminal can fetch a corresponding file from said server for playout as said call greeting, if the file has not been stored in the opposite terminal previously.

25.A terminal according to claim 23 or 24, adapted to use SIP signalling, characterised in that the URN or URL or URI is embedded in an existing header field called ^λAlert info' in an SIP ^Λinvite' message or an SIP ^λ180 ringing' message, respectively.

26.A terminal according to any of claims 15-25, characterised in that said file identity has been predefined for any unknown opposite terminal and refers to a media file containing a default call greeting.

21.A terminal according to any of claims 15-26, characterised in that different file identities have been defined for different potential opposite terminals, and/or depending on the current date or time of the day, week or season, and/or depending on a user status.

28.A first communication terminal adapted to provide a personalised call greeting to an opposite second communication terminal during a setup procedure for a packet-switched multimedia session, characterised by:

- means for identifying the opposite terminal,

- means for retrieving a text string associated with the calling terminal and containing said call greeting, and

- means for sending the retrieved text string to the opposite terminal, wherein the opposite terminal can display the text string as said call greeting.