CA2663316A1

CA2663316A1 - Multiple response options for incoming communication attempts

Info

Publication number: CA2663316A1
Application number: CA002663316A
Authority: CA
Inventors: Goran Eriksson; Didier Chincholle; Ignacio Mas Ivars; Elena Fersman
Original assignee: Individual
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2006-09-18
Filing date: 2006-09-18
Publication date: 2008-03-27
Also published as: GB0906107D0; GB2456695B; WO2008036008A1; GB2456695A

Abstract

An arrangement and method in a telecommunication network for providing a called party with multiple real-time options for responding to an incoming call. A called-party user terminal (23) receives the incoming call from a calling party (21 ) and notifies the called party. A user terminal client (68) provides the called party with a pluraiity of response options and receives a selected response from the called party. The user terminal client (68) sends the selected response to a network server (14), which implements the selected response and sends it to the calling party. The called party may send predefined responses such as tunes or symbols, or may record and send reai-time voice or video bursts.

Description

MULTIPLE RESPONSE OPTIONS FOR
INCOMING COMMUNICATION ATTEMPTS

TECHNICAL FIELD
This invention relates to communication systems. More particularly, and not by way of limitation, the invention is directed to an arrangement and method in a telecommunication network for providing a called party with multiple real-time options for responding to incoming communication attempts.

BACKGROUND
Classical telecommunication telephony services enable a called party to respond to an incoming call by sending a simple busy tone or by referring a calling party to another person or to an answering machine. A recent development enables a called party to send to the calling party, a text message either predefined or written at the time of the cail attempt. Currently, in Japan, mobile users may also respond with melodies, animations, or symbols when they cannot answer (for example, while commuting in public transportation). Furthermore, some mobile networks enable a user to predefine a Short Message Service (SMS) message or a Multimedia Service (MMS) message, which is sent to the calling party upon reception of an incoming voice call.
The existing solution provides few options in the services it provides to users, and is cumbersome to implement. Prior to receiving a call, the called party can direct the call to a person or a machine. If this has not been done when a call is received, the called party can only select to answer or reject the call. If the called party rejects the call, the calling party will hear a busy tone and the call will be logged as a rejected call. If the called party desires to call back the calling party, the called party must access the call list recorded in his mobile phone and send a message or make a phone call.

What is needed in the art is an arrangement and method in a telecommunication network for handling incoming communication attempts that overcomes the shortcomings of the prior art. Such an arrangement and method should provide users with the capability to handle incoming communication attempts in a more flexible and dynamic manner. The present invention provides such an arrangement and method.

SUMMARY
The present invention provides a called party with multiple options for dynamically responding to incoming communication attempts. For example, the called party may reject the call and designate in real time, a personalized busy tone, image, music, audio burst, or video burst to be returned to the calling party.
The called party may also reject the call and refer the calling party to an ongoing communication session. The invention provides for the appropriate interactions between the user and the system, as well as functionality for transporting the response from the called party to the calling party.
The present invention provides users with richer options for managing communications, providing both personalization as well as efficiency. For network operators, the invention differentiates their services with respect to other providers, enabling them to attract additional subscribers. Network operators may also establish connections with external content providers to obtain content such as ring tunes, symbols, or prerecorded audio or video bursts.
Thus, in one aspect, the present invention is directed to an arrangement in a telecommunication network for providing a called party with multiple real-time 26 options for responding to an incoming communication attempt from a calling party.
The arrangement includes a called-party user terminal and network server means.
The called-party user terminal includes means for notifying the called party that the incoming communication attempt has been received, and user terminal client means. The user terminal client means includes means responsive to receiving the incoming communication attempt for providing the called party with a plurality of response options; means for receiving from the called party, a response selected from the plurality of response options; and means for communicating the selected response to the network. The network server means includes means for receiving the selected response from the user terminal client means; means for impiementing the selected response; and means for communicating the selected response to the calling party.
In another aspect, the present invention is directed to a telecommunication user terminal for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party. The user terminal includes means for notifying the called party that the incoming communication attempt has been received, and user terminal client means. The user terminal client means includes means responsive to receiving the incoming communication attempt for providing the called party with a plurality of real-time response options; means for receiving from the called party, a response selected from the plurality of real-time response options; and means for communicating the selected response to the network.
In another aspect, the present invention is directed to an application server in a telecommunication network for invoking a real-time response selected by a called party in response to receiving a communication attempt from a calling party.
The application server includes means for receiving the selected real-time response from the called party; means for implementing the selected real-time response; and means for delivering response content to a core network for delivery to the calling party.
in another aspect, the present invention is directed to a method in a telecommunication network for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party.
A called-party user terminal performs the steps of providing the called party with a plurality of real-time response options in response to receiving the incoming communication attempt; receiving from the called party, a response selected from the plurality of real-time response options; and communicating the selected response to the network. The network performs the steps of receiving the selected response from the user terminal agent; implementing the selected response; and communicating the selected response to the calling party.

in another aspect, the present invention is directed to a method in a telecommunication user terminal for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party.
The method includes providing the called party with a plurality of real-time response options in response to receiving the incoming communication attempt;
receiving from the called party, a response selected from the plurality of real-time response options; and communicating the selected response to the network.
In another aspect, the present invention is directed to a method in an application server in a telecommunication network for invoking a real-time response selected by a called party in response to receiving a communication attempt from a calling parky. The method includes receiving the selected real-time response from the called party; implementing the selected real-time response;
and delivering response content to a core network for delivery to the calling party.
In each aspect, the response may be selected from a group of real-time response options consisting of inviting the calling party to join an ongoing group communication session; sending an identified tune to the calling party;
sending an identified symbol to the calling party; recording and sending a real-time voice burst to the calling party; and recording and sending a real-time video burst to the calling party.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
In the following, the essential features of the invention will be described in detail by showing preferred embodiments, with reference to the attached figures in which:
FIG. 1 is a simplified block diagram of a network arrangement in which the present invention has been implemented;
FIG. 2 is a simplified block diagram of a 3GPP wireless network arrangement in which the present invention has been implemented;
FIGS. 3A-3B are portions of a flow chart illustrating the steps of an exemplary embodiment of the method of the present invention;

_6_ FIGS. 4A-413 are portions of a signaling diagram illustrating the flow of network messages when configuring the RR service in the network and user terminals;

FIGS. 5A-5B are portions of a signaling diagram illustrating the flow of network messages when invoking an RR feature;
FIGS. 6A-6B are portions of a signaling diagram illustrating the flow of network messages when the called party user rejects a call and selects to send a symbol or tune to the calling party user, and SIP transport is utilized;
FIGS. 7A-7B are portions of a signaling diagram illustrating the flow of network messages when a called party user rejects a call and selects to send a symbol or tune to the caliing party user, and a SIP message is utilized to configure an RTP transport channel;
FIGS. 8A-8B are portions of a signaling diagram illustrating the flow of network messages when the called party user rejects a call and selects to send a symbol or tune to the calling party user, and a predefined RTP channel is utilized to deliver the RR content;
FIGS. 9A-9B are portions of a signaling diagram illustrating the flow of network messages when the called party user rejects a call and selects to send an instantly recorded voice, video, or multimedia burst to the calling party user; and FIGS. 10A-10B are portions of a signaling diagram illustrating the flow of network messages when the called party user rejects a call and selects to invite the calling party user to join an ongoing group communication session.

DETAILED DESCRIPTION
The present invention, referred to herein as Rich Reaction (RR) call handling, provides a user several ways of reacting in real time to an incoming communication request, apart from simply accepting or rejecting the request.
First, the user may reject the request and provide additional information to the calling party in a voice or video burst created in real time by the called party.
Second, the user may reject the request and respond with a tune, symbol, or another media format provided by a third party. Third, the user may reject the request and redirect the communication request to another person or device.

Each of the above alternatives is hereafter referred to as "RR features". The features are applicable to any type of communication between users, not just duplex voice communications such as a classical telephony call.
FIG. 1 is a simplified block diagram of a network arrangement in which the present invention has been implemented. The arrangement includes at least two user equipment (UE) terminals such as UEs 11-13 and an RR network server (RRS) 14. UE terminal 11 includes an RR client (RRC) 15, and UE terminal 12 includes an RRC 16. All components of the arrangement are interconnected using a connectivity network 17. The UE terminals and the RRS have functionality to support RR features.
A preferred embodiment uses 3GPP IP Multimedia Subsystem (IMS) technologies, based on the Session Initiation Protocol (SIP). The preferred embodiment assumes the UEs 11 and 12 are SIP end points, with User Agents having RR functionality, that is, RRCs. In the network, the RR functionality is located in an application in a 3GPP application server in the RRS 14. The RRS
mainly provides services to the user receiving calls (i.e., the called party), and is therefore a so-called terminating telecommunications service. The RRS also provides security services to the caliing party and for an optional third party such as a service provider for controlling and managing the RR service.
FIG. 2 is a simplified block diagram of a 3GPP wireless network arrangement in which the present invention has been implemented. User-A 21 is a mobile user operating in Network-A 22. User-B 23 is a mobile user operating in Network-B 24. Network-A includes a core network having a Serving Call State Control Function (S-CSCF) 25 and an Interrogating CSCF (I-CSCF) 26, Network-A also includes a service network 27. Likewise, Network-B includes an I-CSCF
28, an S-CSCF 29, and a service network 30. The typical deployment of the RRS
14 is in the service network, which may be the same network to which the users are attached (one Network-A and one in Network-B), or in a separate network.
Thus, Network-A is shown to include an application server 14a with an RR
server application, and Network-B is shown to include an application server 14b with an RR server application. RR content servers 31 a and 31 b connected to application servers 14a and 14b, respectively, store RR-specific content.

The scenario in FIG. 2 shows User-A 21 placing a call to User-B 23. Using 3GPP IMS and SIP, the preferred embodiment assumes the RRS 14b to be linked into the chain of entities processing the SIP messages implicitly. That is, the RRS
14b is not directly addressed by the users or by the RRCs (or any other entity).
Instead, the RRS is invoked using filters in the S-CSCF 29 via an 1SC
interface.
The filters are configured to trigger on particuCar information in the SIP
requests.
As noted above, the present invention provides the called party with the capability to respond to incoming calls in different manners, and is thus a terminating end-user service. In the preferred embodiment, however, the RR
functionality also incorporates security features acting on behalf of the calling party. Thus, RR content from a called party is subjected to filtering and other security mechanisms before being sent to the calling party. In the preferred embodiment, this functionality is managed by the network portion of the RR
functionality, more specifically by an RRS.
The preferred embodiment of the RRS 14 assumes a J2EE application server (with SIP container functionality)-based implementation, or the like, meaning that a middleware entity intercepts the SIP requests and invokes or informs the application about certain events as configured. The RRS may get linked into the chain of SIP entities operating on the S1P dialogue as a proxy for all requests from and to a particular user (who has RR) and also subsequent responses.
In operation, User-A 21 initiates a call attempt to User-B 23. The invitation includes information about the calling device's ability to support RR
features.
User-B chooses to reject the call and selects an RR type. This may trigger an indication to User-A that the call is rejected, but User-B is responding with additional information. User-B enters the content to be sent to User-A. The particular feature is constructed, and the content is delivered to User-A's terminal according to configurations and processing decisions by the RR entities.
FIGS. 3A-3B are portions of a flow chart illustrating the steps of an exemplary embodiment of the method of the present invention. At step 31, the RR application is configured in the RRCs 15 and 16 in the user terminals and in the RRS 14. The process then awaits a triggering event at step 32. If the RR

configuration is updated at step 33, the process ends. However, if one of the users initiates an outgoing call attempt at step 34, the process prepares for RR
operation in the originating (calling party) device at step 35. At step 36, the process applies outgoing screening filters. Filters for outgoing and incoming RR
messages are available in the RRCs 15 and 16 and in the RRS 14. The RRS and the RRCs analyze the outgoing message and compare it with a policy that decides whether the use of RR is possible and allowed. If so, the RRS and RRCs determine whether there are any restrictions on RR types and implementation (media type, DRM, size, cost, etc.) that apply for the destination or the location of the calling party. The process then awaits a triggering event at step 37.
When a triggering event occurs, there are three possible courses of action, as shown in FIG. 313, If the called party (peer) accepts the call, the process moves to step 38 and ends. Alternatively, at step 39, the called party may reject the call, but the calling party does not receive an RR indication and the process ends. If the called party rejects the call and the calling party terminal receives an RR indication, the process moves to step 40. At step 41, the terminal presents the RR indication to the calling party. The calling party may then activate the RR
service at step 42 or defer the RR service at step 43. If the RR service is activated, the process moves to step 44 where the RR content is retrieved, if necessary, and is presented (audio or visual) to the calling party. If the calling party defers the RR service, the process moves to step 45 where the attempt to establish the call is ended. At step 46, the ongoing RR delivery processes to deliver the RR content to the calling party are canceled. The RR message information is stored in the calling party's terminal.
Referring again to FIG. 3A, if the triggering event at step 32 is the receipt of an incoming call attempt from an RR-capable device, the process moves to step 47. At step 48, the system presents call handling options to the called party user including RR extensions. At step 49, the called party user selects an RR type.
if the user selects to invite the calling party to join an existing group communication session, the process moves to step 50. At step 51 in FIG. 3B, the RRS and RRCs apply screening filters to the call. For example, the group must be open to new participants, and the called party must have permission to invite a new participant.

In addition, it may be required that the calling party have some necessary privileges to join the communication. The process then moves to step 52 where the system delivers and renders the RR type. For example, the system may coordinate with the core network to obtain the calling party's agreement to join the group communication, to join the calling party with the group, and to notify the group of the new participant.
Referring again to FIG. 3A, if the user selects at step 49 to play a tune or send a symbol to the calling party, the process moves to step 53. At step 54 in FIG. 3B, the RRS and RRCs apply screening filters to the response. At step 55, the system selects an appropriate media format, size, and transport mechanism for the user's selected response. At step 56, the system adds the selected tune or symbol to the response. The process then moves to step 52 where the system delivers the tune or symbol to the calling party.
Referring again to FIG. 3A, if the user selects at step 49 to send an instant voice or video burst to the calling party, the process moves to step 57. At step 58 in FIG. 3i3, the RRS and RRCs apply screening filters to the response. The RRS
14b retrieves the voice or video burst from the content server 31 b, and at step 59, selects an appropriate media format, size, and transport mechanism for the user's selected response. The process then moves to step 52 where the system delivers the instant voice or video burst to the calling party.
Referring again to FIG. 3A, if the called party user selects at step 49 to exercise one of the traditional (legacy) responses to answer the call (Yes) or reject the call (No), the process moves to step 60. The existing legacy process is then carried out at step 61 in FIG. 315.
FfGS. 4-10 are signaling diagrams illustrating the flow of network messages for different RR procedures. All use cases are presented for the case in which the RRS 14 is implicitly invoked via triggers in the S-CSCF 29. In other words, the service network is the same as the network in which the called party is registered. The diagrams only illustrate the SIP requests and responses that are relevant for the operation of the RR functionality. It should be understood that other standard SIP messages are also exchanged between the network entities.
Furthermore, the behavior in the end-user terminals is described at a high level, assuming an example realization. A more detailed description of the terminal realization is given separately.
FIGS. 4A-4B are portions of a signaling diagram illustrating the flow of network messages when configuring the RR service in the network and user terminals. In the illustrated case, the calling party user equipment (UE-A) 21 is located in Network-A 22. The calling party user interfaces with UE-A through a user interface (Ui) 64. UE-A includes an RR client 65. An IMS/SIP core network 66 connects UE-A to an IMS/SIP core 67 in Network-B 24. The called party user equipment (UE-B) 23 resides in Network-B and includes an RR client 68 and a user interface 69. A precondition for service configuration is that the RR
functionality has been installed in the user terminals and in the network.

entities including associated databases such as DNS have been configured with routing information and user service data for authentication and authorization.
The RRS 14 is started and is waiting for triggering events. The RRS is configured with an RRS content server address.
At step 71 in FIG. 4A, the RRS 14 requests the S-CSCF in the IMS/SIP
core network to inform the RRS when specific users register. At step 72, UE-A
is powered on, and the RR client 65 starts the RR application. At step 73, UE-A
registers in the network by sending a SIP Register message 74 to the iMS/S1P
core network 66. The SIP Register message includes an indication that UE-A is RR-capable. At step 75, the S-CSCF in the IMS/SIP core network registers UE-A
and informs the RRS that UE-A has registered. The process then moves to FIG.
4B.
At step 76, the RRS 14 triggers authentication and authorization procedures if they have not been performed by the IMS/SfP core 66. The RRS
stores the RR capabilities of UE-A. The RRS may also download user RR
preferences for filtering incoming RR requests from the database. Finally, the RRS pushes information to UE-A about pre-created RR content (for example, symbols and tunes) stored in the network. The information may be provided in the form of pointers, URIs, and information about the content such as format, size, cost, and the like. At step 77, the RRS 14 sends the information about the stored content to the RRC 65 in UE-A. At step 78, the RRC stores the content information, and at step 79 sends an acknowledgment to the RRS.
FIGS. 5A-5B are portions of a signaling diagram illustrating the flow of network messages when invoking an RR feature. The following key procedures are included in the RR preferred embodiment:
= End-user terminals indicate capabilities using media feature tags in the Accept-Contact header.
= An end-user terminal may support different types of RR, for example a subset of the features. This is indicated in either the media feature tag or using the "a" parameter in the SDP carried in a SIP INViTE message.
= FFS: A special RR ring tone may be generated if the peer device supports RR. This requires the RRS to keep track of RR capabilities, and requires an indication of RR ring tone in the SIP 180 message.
= The Reject response includes an RR-type Indication and token identifying the call attempt.
= A message is sent to the calling party using, for example the SIP REFER
message, to transfer RR content.
Note also the following steps in the sequence in FIGS. 5A-5B:
Step 5: The RRS supporting the calling party, also denoted originating RRS
instance, is linked into the routing of the SIP messages by the S-CSCF based on filter criteria set in the S-CSCF. This allows the RRS to create a call state for the outgoing request, and optionally validate that the calling party has the right to receive RR-content, thus reducing delay.
Step 8: The invitation reaches the RRS acting as a proxy for the called party. This RRS is also linked into the routing based on filter criteria in the S-CSCF in the same network as the called party (i.e. the SIP domain in which he is registered). The RRS, also denoted terminating RSS instance, inserts itself in the routing for all SIP subsequent responses and requests. This allows for any third party to apply local policies in restricting the usage of RR.
Step 18: The called party has selected to reject the calf, but responded with an RR feature. A reject is sent back to the calling party, using a SIP 380 message. The following RR information is included in the body of the message:
a token to identify the RR invocation, RR-type, and information about device RR
capability. The SIP 380 message reaches the terminating RRS instance, which may take different actions (some dependent on the RR-type invoked, as discussed below), such as authorizing the type of RR invoked by the called party, or triggering processes preparing for a possible later RR content delivery to the calling party.
Step 21: The reject message with RR-information reaches the originating RRS instance, which may now apply screening based on content, called party identity, or other criteria. These criteria may be set either by the User-A or by a third party.
Step 24: The indication that the called party, User-B, is responding to the invitation is delivered to the calling party, User-A. This indication preferably differs from the existing reject indication (busy tone) so that the calling party is made aware of the difference. The calling party may either wait for the RR
information from User-B, which should be delivered within 5-10 seconds from the indication, or may suppress the RR content being rendered. In the preferred embodiment, the RR content is delivered to the calling party terminal even if the calling party requests suppression.
Step 25 and 26: (This and subsequent steps may run in paralfel with steps 16-24). The called party enters the content to be sent to the calling party, either directly by writing a text message or recording a voice burst, video burst, or the like, or indirectly by selecting a pre-created content, stored in the network.
The information is packaged, for example in a SIP MESSAGE or iNFO together with the same token sent in the reject indication (step 18). The message is tagged with a media feature tag "RR", which is used to route the message to the RRS
applications.
Step 28: The message arrives at the terminating RSS instance, which again may take actions depending on the RR type. Also, third-party services such as charging, or sending of commercials, may be invoked at this point.
Step 31: The message arrives at the originating RSS instance, which may apply screening services.

Step 35: The message arrives at the RRC in the calling party device.
Depending on the RR type, the RRC takes different actions, as described below.
The RRC notifies the user about the RR content with a notification, at which point the user may select to consume the information. The user may also defer the information, choosing to view it later. The RRC stores a message in the terminal inbox (for example, as an SMS, MMS, or an email) enabling the user to retrieve the information at a later time.
FIGS. 6A-6B are portions of a signaling diagram illustrating the flow of network messages when the called party user 23 rejects a call and selects to send a symbol or tune to the calling party user 21 using SIP transport. The symbol or tune may be provided by the called party user or a third party, and may be stored in the network or in the called party terminal (or an associated device such as a memory card). The service includes finding and selecting tune(s) or symbol(s) the called party user feels fit the purpose for a particular call, constructing a response, and delivering the response to the calling party user. When constructing the service, the RRSs 14a and 14b select the transport method used for carrying the burst to the calling party user's terminal based upon the capabilities of the terminal, the transport prerequisites, and the voice andlor media format. In exemplary embodiments, a"S1P Message" message or a Real-time Transport Protocol (RTP) channel is utilized. ln FIGS. 6A-68, SIP transport is utilized.
As preconditions, both user terminals are registered in the IMSISIP core.
Triggers are set in the S-CSCF 29. The RRSs 14a and 14b and the RRCs 65 and 68 are set to manage invocations. Also, it is assumed that the users are authenticated in the IMS/S1P core.
Note also the following steps in the sequence in FIGS. 6A-6B:
Steps 14-16: The called party rejects the call and selects RR type "tune".
The terminating RRC 68 is invoked and the called party user searches the rich tunes and selects a tune by identifying a tune ID. The terminating RRC
indicates this particular RR type in the response to the sender. The terminating RRC
sends a message carrying information about the identity of the selected tune or symbol, for instance in the body of a SIP Message message. If the content is stored iocally in the called party's terminal, the RRC inserts the tune in the SIP
MESSAGE directly.
Step 17: The terminating RRC 68 creates an RR message body, which is included in a SIP 380 response message. The RR message body indicates terminating device RR capabilities, an RR attempt id (token), and the type of RR
invoked by the called party user (tune).
Step 18: The terminating RRS 14b receives the response message and verifies the rights of the user to invoke the feature. The terminating RRS
also finds the tune and analyzes it with respect to the capabilities of the target terminal UE-A 21. The appropriate media format and transport method, SIP MESSAGE or predefined RTP, is used. In the illustrated embodiment, a S1P MESSAGE is used.
The RRS 14ab inserts the tune in the SIP MESSAGE message.
Step 31: The SIP MESSAGE message is intercepted by the originating RRS 14a, which applies screening filters to the RR type, and then analyzes the device capabilities and transport preconditions. Based on this information, a transcoding of the media may be required. Note that this may require the originating RRS, or rather the owner of it, to have the rights to access the content, which may be commercial and therefore encrypted.
FIGS. 7A-7B are portions of a signaling diagram illustrating the flow of network messages when the cailed party user 23 rejects a call and selects to send a symbol or tune to the calling party user 21, and RTP transport is utilized.
In this embodiment, the RR content is downloaded to the calling party's terminal, UE-A, using an RTP channel configured using either a SIP INVITE or REFER message.
The RTP channel may also be pre-configured. The embodiment in FIGS. 7A-7B
assumes the RR content to be stored in the terminating RRS 14b serving the called party. Thus, the RTP channel and the associated SIP dialogue are initiated from the terminating RRS in steps 29 and 38. Alternatively, the content may originate from the called party's terminal (UE-B), meaning that SIP dialogue and RTP transport channels will emanate from UE-B.
The procedure is similar to that of FIGS. 6A-6B until step 26 where the terminating RRC 68 sends a S1P INVITE or REFER message requesting a UDP
port for an RTP stream along with media configuration information associated with the UDP port. The terminating S-CSCF 29 forwards a SIP INVITE message to Network-A 22 requesting the RTP channel.
Note that the originating RRC 65 automatically accepts the session in step 33. Alternatively, the originating RRC may await the calling party user's acceptance to view (and/or listen) to the RR message and then accept the session. If this approach is taken and the calling party user decides not to consume the RR information immediately, the RR message is deferred, allowing the calling party user to retrieve it later. The originating RRC stores information about the RR message, such as an address for the content (if stored outside the terminal), sender, time, and so on. The RRC uses the information to retrieve the content if and when the user wishes to read the RR message later.
FIGS. 8A-8B are portions of a signaling diagram illustrating the flow of network messages when the called party user 23 rejects a call and selects to send a symbol or tune to the calling party user 21, and a predefined RTP channel is utilized to deliver the RR content. In this embodiment, the RRSs and the RRCs have exchanged information about a UDP port for an RTP stream along with media configuration information associated with the UDP port. Each such description of a particular configuration is denoted "predefined RR media port" in subsequent discussions. The RRSs may share information about a number of such predefined RR ports for the RR type "symbol and tunes" as well as for other RR types, notably instant voice and video.
The RRS selects the appropriate transport, in this case "predefined RR
media port using RTP." The information about which port was selected is signaled in the RR message, carried by SIP message in this example, to the originating RRS.
FIGS. 9A-9B are portions of a signaling diagram illustrating the flow of network messages when the called party user 23 rejects a call and selects to send an instantly recorded voice, video, or multimedia burst to the calling party user 21.
In this RR type, the called party user may respond, for example, with an instantly recorded voice or video burst, the burst being transferred to the calling party's terminal immediately without being stored in the network.

The transport method used for carrying the burst to the calling party terminal, UE-A, is selected based upon the capabilities of the terminals, the transport prerequisites, as well as on the format of the voice and/or media format.
In an example embodiment, SIP MESSAGE message or a predefined RTP
channel is used to deliver the RR content. "Predefined" means that an RRC and an RRS have exchanged information about RTP ports to use for delivering RR
content.
Note that at step 25 of FIG. 9B, the terminating RRC 68 records a voice burst as requested by the called party user. The size of the content is kept small enough to fit into a SIP MESSAGE message. The terminating RRC then sends a S(P MESSAGE toward Network-A at step 26 with the recorded RR content and a token. When the calling party user indicates he is ready to receive the burst, the burst is played at step 39.
The voice and video burst may also be transferred to the calling party using RTP channel(s) estabiished via a SIP INVITE or REFER message, similar to the method for transferring tunes and symbols illustrated in FIGS. 7A-7B.
FIGS. 10A-10B are portions of a signaling diagram illustrating the flow of network messages when the called party user 23 rejects a call and selects to invite the calling party user 21 to join an ongoing group communication session.
This RR type gives a called party user who is busy communicating in some way (for example, voice or text chat) the opportunity to invite the calling party into the group communication. In this embodiment, the called party chooses a group among his active groups that he would like the calling party to join. The calling party receives an invitation to join a group with a iist of group participants and the type of communication media. There may be more than one media type available in the group. In this case the calling party receives the invitation to join all media types and can choose to accept or reject any of the media types.
FIGS. 10A-10B illustrate the scenario in which UE-B is involved in a group communication using service X (it can be any service) when UE-B receives a call from UE-A. UE-B sends an RR-reject upon receiving the incoming call, and sends a SIP REFER message to UE-A with the address of the group conference server and the list of participants. If UE-A accepts the invitation, a notification that UE-A

is joining is sent to all group participants. UE-A then joins the group, and notification service is set up for UE-A.
Note also the following steps in the sequence in FIGS. 10A-1 QB:
Step 14: At this step, UE-B rejects the call and chooses "Join ongoing group communication" as the RR-response to UE-A. This step is possible only if UE-B has permission to invite a new participant to some of the ongoing communications. it should be noted that this decision may also be based on UE-A's URi. For example, UE-A may have some necessary privileges to join the communication.
Step 25: UE-B chooses an ongoing communication from the list on the terminal. Each ongoing communication may be one of three types:
= Open - UEWB invites UE-A to the ongoing communication;
= Moderated - only the group moderator or the group owner has a right to add new participants. In this case UE-B makes a request to the moderator/owner to add UE-A; or = Closed - UE-B is not allowed to invite any new participant.
It can be recognized from the foregoing description that the present invention provides many advantages. The users are given richer means to manage communications, providing for both personalization as well as efficiency.
Network operators and service providers can use the invention to differentiate their service offerings in a positive way from those of other providers.
Additionally, the invention will increase traffic in the operator's network, providing for additional revenue-generating events. The invention also provides operators with increased opportunities to establish connections with external content providers for RR
content such as ring tunes.
Although preferred embodiments of the present invention have been illustrated in the accompanying drawings and described in the foregoing Detailed Description, it is understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the scope of the invention. The specification contemplates any all modifications that fall within the scope of the invention defined by the following claims.

Claims

WHAT IS CLAIMED IS:

1. An arrangement in a telecommunication network for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party, said arrangement comprising:
a called-party user terminal comprising:
means for notifying the called party that the incoming communication attempt has been received; and user terminal client means comprising:
means,responsive to receiving the incoming communication attempt for providing the called party with a plurality of response options;
means for receiving from the called party, a response selected from the plurality of response options, wherein the selected response is to invite the calling party to join an ongoing group communication session;
and means for communicating the selected response to the network:and network server means comprising:
means for receiving the selected response from the user terminal client means: and means for coordinating with a core network to obtain the cal1ing party's agreement to join the group communication session, to join the calling party with the group communication session, and to notify participants in the group communication session that the calling party has joined the group.

2. An arrangement in a telecommunication network for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party, said arrangement comprising:
a called-party user terminal comprising:
means for notifying the called party that the incoming communication attempt has been received: and user terminal client means comprising:
means, responsive to receiving the incoming communication attempt, for providing the called party with a plurality of response options:
means for receiving from the called party, a response selected from the plurality of response options, wherein the selected response is to send electronic content to the calling party:
means for prompting the called party to identify the electronic content;
means for receiving an identification of the electronic content from the called party; and means sending the identification of the electronic content to the network; and network server means comprising:
means for receiving the selected response from the user terminal client means:
means for implementing the selected response to the calling party.

3. The arrangement according to claim 2, wherein the electronic content is a tune, and the network server means includes:
means for receiving the identification of the tune from the user terminal agent;
means for retrieving the identified tune from a network database; and means for sending the identified tune to the calling party.

4. The arrangement according to claim 2, wherein the electronic content is a tune, and the user terminal client means includes:
means for retrieving the tune from a database in the terminal; and means for sending the retrieved tune to the network.

5. The arrangement according to claim 2, wherein the electronic content is a symbol, and the network server means includes:
means for receiving the identification of the symbol from the user terminal agent;
means for retrieving the identified symbol from a network database; and means for sending the identified symbol to the calling party.

6. The arrangement according to claim 2, wherein the electronic content is a symbol, and the user terminal client means includes:
means for retrieving the symbol from a database in the terminal; and means for sending the retrieved symbol to the network.

7. The arrangement according to claim 2, wherein the electronic content is a real-time voice burst, wherein the user terminal client means includes:
means for sending to the network server means, an indication that a real-time response is being prepared;
means for interfacing with the called party to record the real-time voice burst; and means for sending to the network server means, the recorded real-time voice burst; and wherein the network server means includes:
means for receiving from the user terminal client means, the indication that a real-time response is being prepared;
means for coordinating with a core network to notify the calling party that a real-time response is being prepared;
means for receiving the recorded real-time voice burst from the user terminal client means; and means for coordinating with the core network to send the real-time voice burst to the calling party.

8. The arrangement according to claim 2, wherein the electronic content is a real-time video burst, wherein the user terminal client means includes:
means for sending to the network server means, an indication that a real-time response is being prepared, means for interfacing with the called party to record the real-time video burst; and wherein the network server means includes means for receiving from the user terminal client means, the indication that a real-time response is being prepared;
means for coordinating with a core network to notify the calling party that a real-time response is being prepared;
means for receiving the recorded real-time video burst from the user terminal client means; and means for coordinating with the core network to send the real-time video burst to the calling party.

9. A telecommunication user terminal for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party, said user terminal comprising:
means for notifying the called party that the incoming communication attempt has been received; and user terminal client means comprising:
means, responsive to receiving the incoming communication attempt for providing the called party with a plurality of real-time response options;
means for receiving from the called party, a response selected from a group of real-time response options consisting of:
inviting the calling party to join an ongoing group communication session;

sending an identified tune to the calling party;
sending an identified symbol to the calling party;
recording and sending a real-time voice burst to the calling party; and recording and sending a real-time video burst to the calling party; and means for communicating the selected response to the network.

10. An application server in a telecommunication network for invoking a real-time response selected by a called party in response to receiving a communication attempt from a calling party, said application server comprising:
means for receiving the selected real-time response from the called party, wherein the selected response is to send stored content to the calling party; and means for implementing the selected real-time response by retrieving the stored content from a content database and delivering the content to a core network for delivery to the calling party

11. A method in a telecommunication network for providing a called party with multiple real-time options for responding to an incoming communication attempt from a calling party, said method comprising:
in a called-party user terminal:
providing the called party with a plurality of real-time response options in response to receiving the incoming communication attempt;
receiving from the called party, a response selected from a group of real-time response options consisting of:
inviting the calling party to join an ongoing group communication session;
sending an identified tune to the calling party;
sending an identified symbol to the calling party;
recording and sending a real-time voice burst to the calling party; and recording and sending a real-time video burst to the calling party; and communicating the selected response to the network; and in the network;
receiving the selected response from the user terminal;
implementing the selected response; and communicating the selected response to the calling party.

12. A method in a telecommunication user terminal for providing a called party with multiple real-time options for responding to an incoming communication attempt from a catling party, said method comprising:
providing the called party with a plurality of real-time response options in response to receiving the incoming communication attempt;
receiving from the called party, a response selected from a group of real-time response options consisting of:
inviting the calling party to join an ongoing group communication session;
sending an identified tune to the calling party;
sending an identified symbol to the calling party;
recording and sending a real-time voice burst to the calling party;
and recording and sending a real-time video burst to the calling party.
and communicating the selected response to the network.

13. A method in an application server in a telecommunication network for invoking a real-time response selected by a called party in response to receiving a communication attempt from a calling party, said method comprising:
receiving the selected real-time response from the called party, wherein the selected response is to send stored content to the calling party; and implementing the selected real-time response, said implementing step including retrieving the stored content from a content database; and delivering the content to a core network for delivery to the calling party.