1. Field of the Invention
The present invention relates to a method of establishing a communications session between first and second devices associated with first and second parties respectively. In one particular example of the present invention, establishment of the communications session is performed using the Session Initiation Protocol. A further aspect of the present invention relates to a database system, a database, a method for retrieving information from a database, and a method for enabling retrieval of information from a database.
2. Description of the Related Art
The Session Initiation Protocol (SIP) is a signalling protocol for creating, modifying and terminating sessions involving one or more participants in a communications network. These sessions include Internet multimedia conferences, Internet (or any IP network) telephone calls and multimedia distribution, with participants in a session communicating via a multicast or via a number of unicast relations, or a combination of these.
The SIP allows session originators to deliver invitations to potential session participants wherever they may be in the network, providing name translation and user location functions to ensure that the call reaches the called party irrespective of their location. The SIP also provides feature negotiation functions which allow the parties involved in a call to agree on the features supported, recognising that not all the parties can support the same level of features (for example, video may or may not be supported). The SIP also provides call participant management functions, allowing a party to bring other parties into the session or cancel connections with certain other parties; parties can also be transferred or placed on hold. Finally, the SIP supports call feature change functions whereby a party in a session is able to change the call characteristics during the course of the call, for example changing the session from one set up as “voice-only” to one that enables a video function. A third party joining a call may also require different features to be enabled in order to participate in the call.
The SIP is an RFC (Request For Comments) standard (RFC 3261) from the Internet Engineering Task Force (IETF). The SIP is an application layer protocol, and takes a modular approach that is free from any underlying protocol or architectural constraints. The SIP has been designed so that it can easily bind SIP functions to existing protocols and applications, such as e-mail and Web browsers, focusing on a specific set of functions. The SIP has also been designed to reuse as many existing protocols and protocol design concepts as possible; for example, SIP was modeled after HTTP, using Uniform Resource Locators (URLs) for addressing and the Session Description Protocol (SDP) to convey session information. With the SIP, each party is identified through a hierarchical URL that is built around elements such as a user's phone number or host name (for example, sip:user@company.com), meaning that it is straightforward to redirect a caller to another phone as it is to redirect someone to a webpage.
The SIP also uses MIME (Multipurpose Internet Mail Extensions) to convey information about the protocol used to describe the session, and as a result, SIP messages can contain Java Applets, images, audio files, authorisation tokens or billing data. The SIP also uses the Domain Name System (DNS) to deliver requests to a server that can appropriately handle them, simplifying the integration of voice and e-mail. Servers along the call path can easily create and forward e-mail messages, and vice-versa, enabling various combined services. The SIP is independent of the packet layer, typically being used over the User Datagram Protocol (UDP) or the Transport Control Protocol (TCP).
The SIP has been adopted by the Voice-over-IP community as its protocol of choice for signalling, and as will be described further below has been chosen as the signalling protocol for establishing multimedia sessions in Universal Mobile Telecommunications System (UMTS) Release 5 IP Multimedia Subsystems (IMS).
FIG. 1 of the accompanying drawings is a schematic illustration of a communications network 1 which uses the SIP to initiate a voice session between a first device 2 and a second device 4. The communications network 1 further comprises a SIP proxy server 6 and an application server 8. The establishment of a voice session between the first and second devices 2 and 4 will now be described with reference to FIG. 2 of the accompanying drawings, which shows one example of the signal exchanges between the various components of the communications network 1 during the course of establishing the voice session.
In step T1, a SIP Invite message is sent from the first device 2 to the SIP proxy server 6. The Invite message is described in detail in the above-referenced RFC document, but in summary it is a text-based message containing certain information relating to the session. For example, the body of the Invite message contains a description of the session, encoded in some protocol format such as the Session Description Protocol (SDP, see RFC 2327). The Invite message also contains a number of text header fields each followed by a string indicating information relating to that field. For example, the “from” field is followed by a SIP URL address of the calling party, while the “to” field identifies the SIP URL address of the called party. Numerous other types of session information can be included in the Invite message, as described in RFC 3261.
In step T2, the Invite message is forwarded to the application server 8, by way of requesting information from the application server 8 relating to the active and available services. In step T3, the application server 8 returns a SIP “200 OK” response having a message body containing the requested information. In step T4, the SIP proxy server 6 sends the Invite message to the second device 4.
Since the Invite message received by the second device 4 contains information relating to the calling party associated with the first device 2, such as the name of the calling party, this allows the called party associated with the second device 4 to see information about the calling party before answering. This is similar to the Calling Line Identification Presentation (CLIP) function of conventional telephony services, where the telephone number of the calling party (and associated name if it is stored in the receiving device) is made available to the called party before answering. The CLIP function is typically enabled using a combination of DTMF (Dual Tone Multiple Frequency) and pole reversal wherein the telephone number of the calling party is sent from the local exchange before the ringing signal. Before the first ringing signal is sent, the called party's CLIP function is activated by the local exchange by reversing the polarity for the DC feed on the subscriber line. The telephone number of the calling party is then sent in the form of DTMF signals to the telephone display of the called party, and only then is the ringing signal sent to the called party.
Returning to the SIP example of FIG. 1, once the called party associated with the second device 4 has checked the information of the calling party associated with the first device 2, the following steps must be performed before the voice session can finally be established. In step T5, the two end parties perform a SDP negotiation in which the media characteristics for the session are negotiated in order to come to a decision on the media streams that can be supported in the session; in this example a basic voice call would be required. In step T6, the necessary resources are reserved for supporting the session, and once resource reservation is completed successfully, in step T7 the second device 4 sends a SIP “200 OK” final response and the first device 2 replies with a SIP “ACK” message to confirm the session set up. In step T8, the voice session has been established, allowing the respective users of the first and second devices 2 and 4 to speak to each other.
As described above, the SIP provides a useful framework for creating, modifying and terminating sessions. Nevertheless, it is desirable to extend the functionality of the SIP and other such session initiation protocols.