Field of the invention

The present invention relates to the field of the transmission and provision of multimedia ringtones by telecommunication devices and networks. Background of the invention

When a phone call is made and the call is set up between the caller and the callee, a forward indication, e.g. ringtone is sent to the callee, and a backward indication, e.g. ringback tone is sent to the caller. A number of improvements are possible for the basic ringtone and ringback tone, for example some handsets provide the option of selecting a specific ringtone for incoming calls from one or more contacts saved in the address book on the handset. These ringtones may also include video, for example watchtones that handset owners can create or download and apply to the contacts in their address book.

Furthermore, the information sent in either direction during the call setup can be added to in a number of ways. For example, from the callee to the caller multimedia ringback tones can be used to greet callers with a selected video, photo or phrase instead of the usual ringing tone. From the caller to the callee, caller identification or "caller ID", namely the phone number that the call originates from, can be sent. It is also possible to supplement the data sent along with the ringtone by including a video, for example animations provided by a service provider, or prerecorded videos uploaded to the service provider forming part of the ringtone during call setup. International patent publication WO201 1/040673 and US patent publication

US2007/0269030 both describe uploading caller identification multimedia content to a server and subsequently transmitting this content to a callee device. These systems require a user to first upload, at some earlier time, visual content to a server in order to use a multimedia ringtone or ringback tone. Alternative ringtone or ringback tone products are desirable to enhance the user experience. Summary of the invention

The present invention generally relates to the communication of early media between terminals in a telecommunication network. Computer systems, including an application server and media server are described to facilitate the communication of early media in real time. The real time communication may be provided as an option in addition to the communication of prerecorded early media, for example media stored within the telecommunication network.

Viewed from one perspective, a method for initiating a call with real time early media includes receiving from a first terminal a session setup message and forwarding the session setup message to a second terminal. A ringback tone is received from the second terminal and forwarded to the first terminal and a ring tone is forwarded to the second terminal from the first terminal. The first and/or the second terminals indicate that real time early media is to be used and the real time early media is communicated between the first terminal and the second terminal.

In some embodiments the early media is transmitted together with the ring tone and/or the ringback tone and may be video data. The video data may be recorded at the first or second terminals or provided by a third party system.

Management of the real time early media function may include implementing a network policy to selectively allow or disallow real time early media. In some embodiments forwarding real time early media includes transcoding the early media. Also disclosed is an application server for implementing the method described above.

Viewed from one perspective a computer system for supporting real time early media transmission over a network before call setup between two terminals adapted to communicate over the network includes an application server configured to allow transmission of real time early media. The application server may transmit real time early media in either direction between the two terminals.

The computer system may include a media server in communication with the application server. The media server may receive the early media, process the media based on network policy limitations and provide the processed media to the application server for transmission to one or both of the two terminals. The computer system may further include a database in communication with the application server, the database adapted to receive, store and/or provide configuration information associated with the two terminals. The configuration information may be used by the application server to manage the transmission of the early media. Viewed from another perspective, a method for initiating a call with real time early media over a network includes a first terminal providing a session setup message indicating the use of real time early media to the network, the network forwarding the session setup message to a second terminal, the second terminal sending a ringback tone to the first terminal via the network, the network receiving an indication from the first and or the second terminal that real time early media is used, the first terminal sending a ring tone to the second terminal via the network, the first and/or second terminal sending real time early media together with the ring tone and/or ringback tone respectively.

Further aspects of the present invention and further embodiments of the aspects described in the preceding paragraphs will become apparent from the following description, given by way of example and with reference to the accompanying drawings.

Brief description of the drawings

Figure 1 shows a schematic representation of a multimedia ringtone system according to one embodiment of the invention.

Figure 2 shows a schematic representation of the caller side of the call setup process. Figure 3 shows a schematic representation of the callee side of the call setup process.

Figure 4 shows a schematic representation of a call that has been set up.

Figure 5 shows a high level message flow according to one embodiment of the invention.

Figure 6 shows a high level message flow for an NGN or IMS network implementation.

Detailed description of the embodiments

Embodiments of the multimedia ringtonc/ringback tone system and method described herein provide a called party with the capability to have a preview of the calling party/receiving party respectively and/or perform other communication functions before call setup, by using a dynamic visual calling line identification (CLI). The before-call-setup communication functions are referred to herein generally as 'Dynamic Multimedia Ringtone' (DMRT) functions. DMRT functions extend early media support for one or both of ringback tone and ringtone. As used herein, the term ringtone refers to the alert forwarded by the network from the caller to the callee before call setup. The term ringback tone refers to the alert forwarded by the network from the callee to the caller before call setup. These alerts form part of the call setup process. When early media is used to supplement a ringtone or ringback tone then early media is sent along with a ringtone alert or a ringback tone alert. The term "early media" has been used to refer to the ability of two handsets, with pr without the coordination from the network, to exchange media contents between each other before the real communication starts. Strictly speaking, "early media" is just enhanced signalling. Although the Session Initiation Protocol (SIP) is used herein to describe the signalling negotiation capability in order to deliver the early media content, it will be understood that the invention described herein may be implemented with any suitable protocol that supports media content exchange before call setup.

Real time early media refers to early media that has not been pre-recorded on an application or a media server. Real time early media can therefore refer to, for example:

• an image, video or sound that is recorded and forwarded to the network at the time that a session setup request is sent to or received from the network, or

• an image, video or sound that has been recorded on a terminal or handset and is then provided to the network as early media at the time that a session setup request is sent to or received from the network.

Real time early media is transmitted directly from a terminal, where the terminal can be a terminal that is originating or receiving a call. The terminal can also be a third party such as a location-based server selected by a call-originating or -receiving handset, for example a server associated with a certain venue where the caller or callee is located. For this arrangement the caller/callec configures the DMRT application to use media originating from the third party. either by using GPS functionality in the DMRT application, or using special feature codes as described elsewhere herein.

1. System overview

An embodiment of a DMRT system 100 can be understood with reference to Figure I . The DMRT system 100 includes handsets 102 and 104, a service provider's DMRT application server 106, a network 108, a service provider's multimedia server 1 12 and a database 1 10.

1.1 Handsets

The handsets 102. 104 are conventional video-capable handsets such as mobile phones or smart phones which are associated with the network 108. The handsets can also be computers or PDAs or any terminal suited to make a call over the relevant network. It will be appreciated that while only two handsets are shown in Figure 1. in reality there may be any number of handsets associated with the network 108 that can support the DMRT functions described herein. If one of the handsets is not video-capable (for example a conventional telephone), then DMRT functionality can be disabled and or configured accordingly during the call setup. For example, if a caller uses a conventional telephone they can upload pre-recorded videos (e.g. using the Internet) to the multimedia server 1 12 for use during call setup with one or more handsets that are able to receive video and/or multimedia content. For this scenario unidirectional DMRT functionality is provided instead of bidirectional or multidirectional DMRT functionality when both all the handsets are video-capable. In one embodiment the DMRT functionality is provided as part of a basic telephony service. In this embodiment DMRT functionality is automatically available and can be enabled by any user for their handset/s.

In another embodiment DMRT functionality is provided as a service that a user must subscribe to. In this subscription model there will be some users using DMRT and some that are not; consequently the service provider can provide full, limited and/or no DMRT functionality for calls involving a combination of subscribers and non-subscribers.

The calling handset (for example handset 102) may be connected to the application server 106 via either fixed broadband network, e.g. DSL or Cable, or a wireless network, e.g. a 3G/LTE network. The supporting protocol can be SIP, H.323, or any other communication protocol supporting early media. A DMRT application on the handsets 102, 104 supports the transmission of a DMRT indicator together with a session setup request, as well as the transmission of early media together with a ringtone and or ringback tone. The application can be downloaded from the application server 106 or the application can be implemented in embedded software provided as part of the handset hardware.

Alternatively, the network policy can be implemented in the application server 106.

In some embodiments, the caller handset allows the user to select between one of the following ringtone options:

1. A simple call with no enhancement to the ringtone. 2. A call with current view, i.e. real time video as the calling identity display media.

3. A call with pre-recorded content, e.g. video or a still image as the calling line identity display media.

This selection can be done by using software menus on the terminal as provided by the software DMRT application, by configuring general settings on the phone that are not necessarily associated directly with the DMRT application, by using a special feature code as a call prefix as described elsewhere herein, or by any other suitable means.

If the caller uses a non-intelligent handset, e.g. ATA (Analogue Telephone Adapter), option 1 is selected. A non-intelligent handset can also rely on the network to provide additional services based on the specific subscription, for example to deliver pre-recorded content as CLI display media.

In one embodiment SIP and Session Description Protocol (SDP) are used to manage the multimedia communication and the DMRT application is based on the SIP and SDP call setup protocol. In this embodiment the caller's handset supports the use of the P-Early-Media header (RFC 5009). The header includes information relating to the use of early media. Instead of simply populating a 'supported' field in the header, the handset adds a directional indicator. This gives a clear indication to the network what kind of forward early-media is going to happen. Examples of directional indicators used in the header are shown in Table 1 :

The callce's handset can also support the use of the P-Early-Media header as an indicator and provides resource allocation in order to receive the early media stream. At the same time, it uses a SIP 183 Session Progress response when receiving an INVITE message, i.e. a session setup message when call setup is being initiated. It will indicate its support to only receive the media stream by using the "'recvonly" attribute in the SDP 'answer' body. Similarly, two-way media support is indicated by using the "sendrecv" attribute.

In one embodiment the callce's handset also provides multimedia ringback tone services according to the DMRT which means that prc-rccordcd data or real time video is transmitted together with the ringback tone. For this embodiment the callee's handset needs to use "sendrecv". Otherwise, "recvonly" is the preferred attribute in the SDP answer.

1.2 Application and media servers

The application server 106 can be any telephony server supporting voice and data services that is adapted to support DMRT. This can be a converged telephony server which supports different generations of network technology (for example the Alcatel-Lucent S420 CTS). The application server 106 manages the DMRT application and provides management and control of real time early media. The application server 106 interfaces with media server 1 12 which in turn provides media processing functionality. The media server can be any suitable media resource server (for example the Alcatel-Lucent 5900 MRF) that is adapted to support DMRT.

When a session setup/progress message with a P-Early-Media header indicating the use of DMRT is received rom the caller/callee by the network , then the DMRT capability and/or subscription of both the caller handset 102 and the callee handset 104 is verified by the DMRT application server 106. This can be done by referring to the database 1 10 (which includes a feature subscription database) when interpreting the call setup messaging content received from the handsets. If DMRT is available for both handsets (based on handset capability, network coverage and/or subscription details), then unidirectional and/or bidirectional multimedia transmission is enabled between the caller handset 102 and the callee handset 104 (or multidirectional multimedia transmission if multiple handsets are used, for example in a conference call). If DMRT is only available for one handset, the service provider can enable unidirectional multimedia transmission and/or can limit or prevent any multimedia transmission. The multimedia is sent from the caller handset 102 to the callee handset 104, and or multimedia is sent from the callee handset 104 to the caller handset 102. The callee handset (for example handset 104) receives the multimedia ringtone via the application server 106 which manages the use of real time early media. The application' server 106 operates together with the media server 1 12. When a call is being set up, the application server 106 forwards an INVITE message from the caller to the callee, which can use the media server 1 12 address for connection depending on the network policy. Λ forward early media indication is provided in order for the callee to allocate resources to support the early media stream. Such indication is delivered together with the INVITE message.

When real time early media is transmitted together with a ringtone and/or ringback tone, the early media may be subject to network policies. For example, bandwidth allocation may be indicated correspondingly when the network is using a certain Quality of Service (QoS) control. For the early media to adhere to the requirements of the network policies, the early media may require processing. This processing is performed by the media server 1 12. The policy requirements may relate to early media contents (e.g. video-only vs. video/audio), early media length (e.g. one frame video), and preloading of early media. The media processing required for implementing the network policies, and performed by the media server 1 12, may include transcoding (transcoding comprises data format conversion, for example to accommodate bandwidth limitations).

In order to support a flexible DMRT scheme, the application server 106 supports at least the two call scenarios described below (with reference to an embodiment using the subscription model as described above). i. DMRT on the A-party (caller)

DMRT functionality is configured in both the handset and the database 1 10. Referring to Figure 2, when the caller 200 initiates a call with a call setup 201 indicating the use of DMRT (for example by using a P-Early-Media header), ihe DMRT application server 106 will first send a subscription query 202 to the database 1 10.

Query 202 is used to check:

1. Is the caller allowed to use DMRT, i.e. does the user have a DMRT subscription ? 2. If so, what kind of content will the callee use: real-time or pre-recorded multimedia.

Pre-recorded multimedia will be associated with a content ID used for retrieving the content when a call is being made.

^' If DMRT is not supported, then call setup will proceed according to conventional methods and the application server 106 will remove all DMRT indications from the caller. A network setting may be configured whereby default media (e.g. an image or a sound) is used for display during the call setup if DMRT is not supported.

If DMRT is supported, the application server 106 will further check if media conversion (e.g. convert video/audio to video-only) is needed. Any required conversion will be performed by the media server 1 12. If real time content is sent with the ringtone then the content is streamed either directly from the caller 200 or converted by the media server 1 12 with the coordination from the application server 106 across the network 108. Media server 1 12 is used to implement any relevant network policies for media content conversion in terms of media type, media length, etc. When network policies are implemented, the result from the subscription query 202, the checking result 204, is pushed from the DMRT server 106 to the media server 1 12 to prepare the potential incoming media before the call setup. This may include transcoding as described above.

If pre-recorded multimedia content is used for the DMRT then the media server 1 12 is inserted into the media path so that system default content or pre-defined content is used. In this case the result from the subscription query 202, the checking result 204, is pushed from the DMRT server 106 to the media server 1 12 to prepare the potential incoming media before the call setup.

The DMRT application server 106 supports the end user to upload their preferred multimedia content via the web interface (Ut interface as defined in the 3GPP standards), either for real time video streaming, or when pre-recorded video data is being saved to the media server 112 before a call is made. ii. DMRT on the B-party (callee)

Referring to Figure 3, after receiving the SIP 183 response from the callee 300, the application server 106 will send a subscription query 302 to the database 110 to confirm if the callee 300 has a DMRT subscription. Query 302 for the callee is equivalent to query 202 for the caller as described above, and includes the ringback tone content ID where appropriate.

If the system is doing media conversion, or the system default content or pre-recorded media content is used, then a media server connection 304 is established with the media server 1 12, following which the call setup 306 with the callee 300 is completed whereby the media content provided by the caller 200 are delivered to the callee 300.

Referring to Figure 4, when DMRT service is active for either the caller 200 oe the callee 300, then the media path will be set up with media server 1 12 in the middle to either provide the multimedia ri gtone in the forward direction 402 or the multimedia ringback tone in the backward direction 404. The multimedia for both the ringtone and the ringback tone can be uploaded to the media server 1 12 via the application server 106 using a standard interface like a 3GPP Ut interface 406.

1.3 Network

The network 108 is conventional in terms of, for example, signalling and routing, except that the network 108 includes the application server 106 in the path for call setup between the handsets 102, 104. For example, the network 108 can be an NGN/IMS network that supports 3G, GSM, VoIP and/or VoLTE.

A DMRT solution implemented in an NGN/IMS network may be built upon existing multimedia ringback tone services and the SIP will then be used for controlling multimedia communication sessions over IP. In some embodiments, when a SIP client that supports DMRT initiates a video call, the caller can choose to use the current view captured by the camera or an existing video clip stored in the network to send over to the callee. Existing video clips can be pre-recorded by the user and uploaded to the service provider's multimedia server 1 12, video clips such as animations may be purchased by the user and uploaded to the multimedia server 1 12, and/or video clips can be used that are already on the server 1 12, for example video clips provided by the service provider.

For the DMRT solution described herein the assumption is that end users are allowed to use early media with both video and audio content, although the DMRT provides for the audio content to be filtered or changed either at the handset 102, 104 or in the network at the application server 106 or media server 1 12. For example, as a value-added service, the service provider may remove the audio stream from a real-time multimedia ringtone when delivering it to the called party.

In addition to real time video, pre-recorded video and animation, the multimedia can also be one or more live captured still images, time-delay still images and/or audio. The multimedia is transmitted in the format of standard data files (for example AVI for video or JPEG for images). The multimedia may also be transmitted in other formats, for example proprietary multimedia data formats associated with DMRT.

Via the Ut web interface 406 on the DMRT application server 106, Users have the choice to either purchase ready-made multimedia clips and/or upload their own content onto the media server 1 12. When the end user chooses to use pre-recorded content as the ringtone, the content may be delivered either via the Ut interface or as part of early media. Content management is not applicable when real time video is used with the ringtone ringback tone but the media server 1 12 still performs media processing functions such as: · To filter out the audio component of real time multimedia in the network;

• To control the length of the media content,; and/or

• Transcoding media to comply with bandwidth limitations. 1.4 Database

The database 1 10 is used to manage both the DMRT subscription information as well as the multimedia content. The database includes records of subscribers and associated multimedia. The records enable the network to accommodate the transmission of the multimedia data files and include information such as multimedia content type, playing time, file names and sizes etc. The database is a linked multimedia database, which stores metadata that links to the resources on the media server. The database can be built upon any commercially available products, e.g. Oracle or Microsoft SQL Server.

For a peer-to-peer implementation (described below), the use of a database is optional.

2. Call set up using OMRT

Referring to Figure 5, a high level message flow diagram 500 is shown indicating how DMRT works between clients and the network.

1. When client A 502, which supports DMRT, sends a session setup message 504 (for chat, call, etc), the message 504 includes a DMRT indicator 508 in the signalling part to indicate client A's support of DMRT.

2. When the network 506 receives the session initiation request 504 from client A 502, the network 506 will evaluate it's policy regarding: a. Is DMRT allowed for client A? b. How long is the DMRT media allowed to pass to the other end (for example 5 seconds)? c. Is DMRT allowed to carry video as well as audio?

In one embodiment the DMRT provides for the audio content to be filtered or changed either at the handset 102, 104 or in the network at the application server 106 or media server 1 12. It will be appreciated that additional or alternative policy features (as compared to a.-c. above) may be implemented by the network depending on the relevant protocol/s and/or support provided by the network for the DMRT application.

3. If the network 506 completes the DMRT policy check 509 and the use of DMRT is allowed, then the network 506 will pass the request 510 to client B 514, together with the DMRT indicator 512.

4. When client B 514, which also supports the DMRT feature, receives the request 510, 512, it will return a 'ring' message 516. At the same time, it will prepare the media resource on client B (i.e. the socket allocation) in order to accept incoming DMRT media in the form of incoming IP packets. 5. The 'ring' message 518 is forwarded to client Λ 502 who then initiates the dynamic media transmission towards the network in the form of a multimedia ringtone 520 comprising a ringtonc together with real time or pre-recorded media (e.g. video) and the DMRT 520 is forwarded to client B 514. Depending on the network setting, client A 502 could also receive a media stream from the network 506, e.g. a multimedia ringback tone 522 comprising a ringback tone together with real time or pre-recorded media (e.g. video) from client B 514. Early media is set up at event 523.

6. To progress to the actual call setup, client B accepts the session and returns back an OK message 524. 7. The network 506 passes the OK message 526 to client A 502. Two-way real time communication 528 commences at this point.

Figure 6 shows the signalling used for the call setup using DMRT in the case of an NGN/IMS network. The calling party 602 sends a SIP INVITE 604 to initiate call setup which includes a P-Early-Media header indicating the use of DMRT. When the forwarded SIP INVITE message 610 is received by the called party 614, the called party's SIP client sets up the video display as part of early media negotiation. The called party 614 then sends a 183 Session Progress message 616 to the NGN/IMS core network 606, which in turn forwards the 183 Session Progress message 618 to the calling party 602. For the 183 responses to be transmitted reliably, the calling party 602 returns a progress acknowledgement message PRACK 630, which is forwarded to the called party in 632. 200 OK responses for the PRACK are then passed on from the called party 614 to the network (634) and later (636) to the calling party.

Early media flow 623 is then setup between the two parties. DMRT ringtone 620 will be setup from the calling party 602 to the called party 614. Multimedia ringback tone 622 is also possible from the called party to the calling party with the coordination of the network. When the called party 614 picks up the call, 200 OK response 624 is returned to the network and subsequent OK response 626 is sent to the calling party. The calling party 602 will return the acknowledgement ACK 640 to the network and subsequent ACK 642 is sent to the called party. Here the two-way real time communication 644 commences. In one embodiment CLI is displayed as a subtitle of the received video stream. When the called party 614 picks up the phone, a normal video call will start.

3. Additional features

The DMRT solution can be done in either peer-to-peer mode or network-based mode. These modes support a number of additional features over and above the basic DMRT functionality as described above.

3.1 Peer-to-peer mode

For peer-to-peer mode, the solution will rely on enhancements to the handsets. At the same time, it is subject to the network bandwidth and media stream policy check, which controls a subscriber's use of early media and media content (audio vs. video). When there is no policy restriction of the use of early-media, the client will provide local media conversion, e.g. record video content only before sending to the called party. The client will still indicate the use of DMRT by certain indications in the call setup messages. The call flow is similar to the one shown in Figure 5 but without the presence of the network element. In the peer-to-peer mode additional features include the caller choosing to use a prerecorded video or image saved on the caller's handset to be the multimedia content used as early media instead of real time video. Another additional feature is to upload content associated with different categories. Possible categories can be, for example, contact group or content type, location-dependent content, content dependent on the time of day that the call is made, dependent on another time variable, such as the day of the week, the month, or day in the calendar or year.

3.2 Network-based mode

For the network-based solution, DMRT runs under the same policy control but provides more flexibility for both the service provider and the end user. Additional features described above with respect to the peer-to-pcer solution can be expanded on in a network-based solution. For example, categories that multimedia content is associated with can further include ringtone/ringback tone categories dependent on the callee's identity or the callee ^' s location. When the presence service is provided by the network operator, such multimedia contents can be linked with the presence information, e.g. avatar icon, on-line status, etc. When a caller makes a call, the network can automatically pick up the caller or callee's location (either with the SIP P-Access-Network-info header or presence update) or their mode, which is associated with the presence service (e.g. hyper-available as defined in the GSMA RCS) to decide which content to deliver if content has been categorised according to location. For example, real time video content may be delivered when the caller is in location A (e.g. a street), while pre-recorded audio content may be delivered when the caller is in location B (e.g. a hospital).

Further, a special feature code can also be configured for the end user to use as the calling prefix to turn the use of different categories on or off or to indicate which multimedia content to use. If the default setting is to allow DMRT for all calls, then #33. for example, can be defined to disable DMRT and #34 to use a pre-recorded multimedia ringtonc. The user can dial #33<...> to call the network to disable the multimedia ringtone or dial #34<...> to use pre-recorded contents, where <...> refers to codes associated with configuration options.

A network mechanism is also provided for controlling the display and overriding the multimedia CL1 display. For example, the network can limit the early visual content delivery time. As early-media content consumes network bandwidth, service operators will normally implement policies such as the length the media is allowed to play. In order to implement such a limitation, media server 1 12 is used to provide media conversion. For example, when forward early media is connected from the calling party to the media server, it will capture the first frame and convert it to a static image to be sent to the called party.

The multimedia ringtone/ringback tone system and method described herein provides a called party with the Capability to have a preview of the calling party before call setup by using a dynamic visual calling line identification. From the callee's point of view, being able to view the caller in real time, instead of simply being prompted with a name text, an image or a piece of music for the incoming call, provides another level of user experience. Real time visual identification may also be used for additional authentication purposes, for example a callce may be provided with additional information about whether the incoming call should be handled urgently or not. This could be useful for emergency calls or even fraud prevention.

It will be understood that an NGN/IMS network implementation using SIP to support the DMRT application as described herein is one example of an implementation of the invention. Any communication network with any type of architecture and protocols would be suitable as long as video data can be accommodated. For example, the DMRT system and method as described herein can also be implemented using H.323 or http-based protocols.

It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.