This invention relates to telecommunication networks and, more specifically, to providing ringback services to user devices.
In a traditional wireline telephone system, ringback is the audio sound sent by a switch to the telephone of the calling party prior to call path connection to a called party. Such traditional ringback consisted of periodic tones used to convey to the calling party that the telephone of the called party was ringing.
Because an Internet Protocol (IP) Multimedia System (IMS) utilizes packet networks instead of traditional wireline circuit-based networks, ringback has to be generated and provided by other than a telecommunication switch. A known method of generating the ringback tones is local generation of the tones at the calling party equipment, upon receiving an appropriate signal from the network; however, the end-user's experience in such cases is limited to experiencing from one of the finite pre-stored ringback tones on the end-user device. Another known method of providing ringback in an IMS uses a Session Initiation Protocol (SIP) “Alert-Info” messaging. This functions as a client pull technique where the calling party is the client and the IMS is the network from which the ringback information is pulled by the client.
Multimedia ringback services where the ringback information includes other than normal audio content such as video, etc. is disclosed in U.S. patent application Ser. No. 11/027,298. This method requires substantial signaling and/or messaging among end user devices and network elements to provide such ringback service and also depends on a client pull for rendering multi-media contents.
It is an object of the present invention to provide an advance in ringback services.
An exemplary method provides ringback information to a calling party device. A call establishment request is received in an Internet Protocol (IP) Multimedia Subsystem (IMS) network from the calling party device by a session initiation protocol, SIP, application server, SIP-AS. Ringback information associated with the called party is identified in response to the call establishment request. A push transmission technique is used by the SIP-AS to transmit the ringback information via one or more messages sent from the SIP-AS to the calling party device.
A computer readable medium containing a software program, when executed by a computer, causes the computer to perform a method as generally described in the above exemplary method.
An exemplary session initiation protocol, SIP, application server, SIP-AS, is adapted to provide ringback information to a calling party device. It includes a mechanism for receiving a call establishment request from the calling party device. It identifies ringback information associated with the called party in response to said call establishment request. Further, it transmits the ringback information via one or more messages to the calling party device using a push transmission technique.
Features of exemplary implementations of the invention will become apparent from the description, the claims, and the accompanying drawings in which:
End-user devices comprise communication devices of telecommunications subscribers that can initiate and/or receive calls. Such end-user devices may comprise wireless communication devices such as cellular telephones, personal digital assistants, computers with wireless modems, etc. as well as wireline communication devices such as traditional telephones, IP telephones, SIP telephones, and computers and/or personal digital assistants connected by wireline.
The exemplary IMS 10 of
In step 100 the user of device 14 initiates a call to device 20 which is received by CSCF 56 functioning as a SIP proxy as an SIP INVITE containing associated session description protocol (SDP) information about device 14 which is in turn sent to CSCF 58. If the caller is in a legacy circuit network (PSTN) instead of the IMS (as shown), a Media Gateway (MGW) and Media Gateway Control Function (MGCF) act as the PSTN protocol to SIP interworking point and provides the SIP user agent interface to the IMS. In this example, CSCF 56 is assigned to support access systems including user device 14, and CSCF 58 is assigned to support access systems including user device 20. In step 102 CSCF 58 forwards the SIP INVITE to element 61 based on the initial filter criteria (IFC) for the called party, i.e. the user associated with device 20. Element 61 accesses the profile of the called party and determines based on stored control information in the profile that specialized ringback information is to be played to the calling party. Element 61 prepares to start streaming the stored audio information as ringback information to the calling party by sending a SIP 183 Session Progress message towards the calling party, i.e. by CSCF 58, in step 104. The CSCF 58 in turn transmits the SIP 183 Session Progress message to indicate that the initial portion of the session set up is successful and progressing to the calling party device 14 in step 106. The 183 Session Progress message contains an SDP in response to the SDP contained in the Invite 100,102. It is this exchange of SDP information between calling and called party devices that enables a real-time protocol (RTP) media session to be established as explained below. In response, the calling party device 14 transmits a provisional acknowledgment (PRACK) to CSCF 58 in step 108, which is relayed to element 61 in step 110. The PRACK acknowledges valid receipt of the SDP information in the 183 Session Progress message. The element 61 acknowledges receipt of the PRACK message by transmitting a 200 OK message to indicate that the PRACK was received to the CSCF 58 in step 112 which is in turn relayed to the calling party device 14 in step 114.
In accordance with step 116 element 61 transmits an SIP Early Media message stream including the specialized ringback information to device 14. This involves the SIP-AS 50 identifying and retrieving from MRS 62 the particular information, e.g. audio or other types of digital information, as predetermined by the called party. This information is transmitted by SIP-AS 50 as a stream of SIP Early Media packets to the calling party device 14 using IP network as the bearer. Although step 116 is illustrated following step 114, step 116 is concurrently processed and generated by element 61 following the receipt of the INVITE message at step 102, i.e. the SIP Early Media packets will be transmitted in parallel with the events associated with steps 104-114. For example, the calling party device 14 may receive a first SIP Early Media packet prior to the receipt of the SIP 183 Session Progress message indicated in step 106. This is specially the case when the signaling and bearer traffic follow different routes to the calling party device 14.
In step 118 element 61 initiates a call to the called party by sending a SIP INVITE message to CSCF 58 which relays this message in step 120 to the called party device 20. The SDP information carried in this message is the same SDP information received by element 61 with the INVITE message associated with step 102. Element 61, and in particular the SIP-AS 50, functions as a back-to-back end-user agent (B2BUA) in the illustrative embodiment. That is, in addition to element 61 terminating the call request (the INVITE message of step 102) from the user associated with device 14, it also serves to generate a new call request (INVITE message of step 118) directed to the called party device 20.
Assuming that the called party device 20 is free to accept the call, the called party device 20 responses in step 122 with a SIP 180 Ringing message transmitted to the CSCF 58 where the ringing message includes SDP information carrying the codec selected by device 20 as the best choice of the commonly acceptable codecs offered by device 14 and supported by device 20. That selected codec and respective port map are returned in the SDP in the 180 message in step 122. This information is relayed from CSCF 58 to element 61 in step 124. Similar to the PRACK (108, 110) and the 200 OK PRACK (112, 114), element 61 sends a PRACK to the user agent server on the called party device 20 and receives back a SIP 200 OK (PRACK) in response (not shown). This response acknowledges receipt of the SDP information prior to execution of step 126.
In step 126 called party device 20 goes off hook and causes a SIP 200 OK message to be transmitted to CSCF 58 which in turn relays the message to element 61 in step 128. Element 61 updates the session parameters from the value negotiated in the Early Media session (step 116) to reflect the session parameters received in the SDP information from device 20. The SIP UPDATE session parameters are transmitted from element 61 to CSCF 58 in step 130 and from CSCF 58 to device 14 in step 132. In step 134 device 14 transmits a 200 OK message (to confirm the codec negotiations via SDP) to CSCF 58 which in turn relays this message to element 61 in step 136. This permits the SDP parameters to be mutually agreed upon between devices 14 and 20, and thus permits the selection of a transmission protocol, e.g. codec algorithm, etc., that can be understood by both devices 14 and 20.
In step 138 element 61 sends a 200 OK (to invite) message to CSCF 58 which is relayed to device 14 in step 140. This is in response to the initial SIP INVITE message received in step 102. An acknowledgment (ACK) to the message received in step 140 is originated by device 14 and transmitted in steps 142, 144 and 146 to the CSCF 58, element 61 and device 20, respectively. This results in an end to end voice communication path between devices 14 and 20 being established as indicated in step 148. Note that prior to sending the 200 OK (to invite), billing for the call does not begin; in other words, the Early Media session that provides the specialized ringback tones does not incur any costs for the calling parties before the called party answers. It will be noted that this communication path actually consists of two linked communication paths: one communication path between device 14 and element 61, and another communication path between element 61 and device 20. Thus, element 61 (SIP-AS) functions as a B2BUA. It should also be noted that the Early Media messaging originated by element 61 has effectively morphed into a real-time communication path between the end-users.
In this example it is assumed that user of device 14 is the first to terminate the established communication path. Upon device 14 going on hook, a BYE message is originated by device 14 and transmitted in steps 150, 152 and 154 to CSF 58, element 61 and device 20, respectively. Acceptance of the BYE messages by CSF 58, element 61 and device 20 are confirmed by the transmission of responsive 200 OK (to BYE) messages to the respective sending elements (not shown). This effectively tears down the established communication path and releases the network elements that were supporting the communication path. Although not described, it will be apparent to those skilled in the art that the tear down of the establish communication path can be initiated by either the calling or called party.
It will be appreciated that SIP Early Media messages are sent from the IMS network as a “push” operation to the client/user as contrasted with a client/user “pull” operation that is utilized with SIP alert-info messaging. Although device 14 initiated a call request (steps 100, 102), no request was made by device 14 to receive the information conveyed by the Early Media messaging. Hence, the ringback audio information originated from the IMS network as part of the Early Media messaging constitutes a push operation to device 14. In general, from an end-user's perspective a push operation involves the receipt of information or at least the tendering of the information to the end-user without the end-user first having made a request for that information. In a pull operation the end-user must first request the specific information which is then acquired or pulled from a network. The push of early media to the calling party or SIP agent for the calling party (in the case where the calling party is in the legacy PSTN network) provides an advantage in terms of compatibility with systems that are designed to receive audible ringback in the bearer path as is currently supported in the legacy PSTN.
In accordance with the above-described embodiment, element 61 serves as a ringback platform and functions as a B2BUA. Accordingly, element 61 remains in the signaling path including the voice communication path until the call is terminated.
It will also be noted that the ringback platform uses the SIP UPDATE messaging to effectively change the established Early Media session into a real-time protocol (RTP) media session that supports voice conversation between the end-users.
Although exemplary implementations of the invention have been depicted and described in detail herein, it will be apparent to those skilled in the art that various modifications, additions, substitutions, and the like can be made without departing from the spirit of the invention. For example, certain steps may be arranged in a different order as long as the desired overall functionality is maintained. Various architectural elements can be combined into a single element if convenient or desired. For example, the role of the SIP-AS may be divided between a front-end and a back-end processing element. Similarly, responsibility for performing a function can be transferred to other elements. The embodiment of the present invention may be implemented in software and/or a combination of software and hardware. For example, the methods performed by SIP-AS and MRS can be performed by program control instructions loaded into memory 84, 86, 88 for access and execution by microprocessor 82. Therefore, such methods of the embodiments of the present invention can be stored on a computer readable medium or transmission carrier.
The scope of the invention is defined in the following claims.
This application is related to U.S. patent application Ser. No. 11/027,298 entitled “Method and Apparatus for Providing Multimedia Ringback Services to User Devices in IMS Networks”.