The present invention relates to Session Initiation Protocol (SIP) signalling and more particularly to signalling handled and generated by so-called SIP exploders.
To facilitate the provision of multimedia services via the packet switched “domain”, the 3rd Generation Partnership project (3GPP) responsible for the 3G standards has been developing a so-called IP Multimedia Core Network Subsystem (IMS). IMS communicates with the packet switched access network (e.g. GPRS) and contains all elements that are used to provide IP based multimedia services. For a mobile to mobile call, and assuming the mobiles belong to different networks, an IMS will be provided in each mobile's home network. Each IMS is connected to the GPRS network of its home network. The base protocol for multimedia services is the IETF Session Initiation Protocol (SIP)-RFC3261. SIP makes it possible for a calling party to establish a packet switched session to a called party (using so-called SIP User Agents, UAs, installed in the user terminals) even though the calling party does not know the current IP address of the called party prior to initiating the call. SIP provides other functionality including the negotiation of session parameters (e.g. Quality of Service and codecs, with the help of the Session Description Protocol), the control of ongoing sessions, and the tearing down of sessions.
SIP is of course designed for use with any IP based network architecture and is not limited to 3G networks. In particular, SIP may be used to establish and control sessions over the Internet or IP LANs/WANs.
The concept of the SIP “exploder” has been recently introduced in order to support various functionalities and services including presence services, Push to Talk over Cellular (PoC), Push to Show, etc. These functionalities/services have in common the need to distribute messages to members of pre-defined groups of receivers or to an ad-hoc group of receivers. The SIP exploder is a concept borrowed from email services where a similar need arises, i.e. the same email messages must be distributed to members of pre-defined mailing lists, or to a number of destinations addresses included in the message itself. The SIP exploder is considered in: (1) IETF: Requirements for Session Initiation Protocol (SIP) Exploder Invocation, draft-camarillo-sipping-exploders-01.txt; (2) IETF: Session Initiation Protocol (SIP) Exploder Invocation, draft-camarillo-sipping-exploders-01.txt; and (3) IETF: Session Initiation Protocol (SIP) Exploder Invocation, draft-camarillo-sipping-exploders-solution-00.txt The SIP exploder recognises list identifiers contained within SIP Universal Resource Identifiers (URIs) and acts accordingly. For example, the URI sip:list33@somedomain.com (the portion “somedomain.com” identifying the home network within which the exploder is located) is recognised as referring to the list number 33. The SIP exploder then duplicates the associated message for each of the members of that list, and passes the messages to the Serving Call/Session Control Function (S-CSCF) for transmission to their destinations.
A number of application servers (ASs) 6 are attached to the S-CSCF 5. These ASs provide various intelligent services to the IMS. The SIP exploder introduced above is implemented in such an AS.
It might be the case that a list held by a SIP exploder contains URs belonging to other networks. Some of these URIs may themselves correspond to lists, the members of which are known only to the exploders of those other networks.
For each network, a number of user terminals are shown, each of which communicates with the associated SIP exploder via the packet switched access network and the IMS: Exploder 1 serves a number of terminals identified as Terminals 1.1, 1.2, 1.3 and 1.4, Exploder 2 serves two terminals identified as Terminal 2.1 and Terminal 2.2, and so on. If Terminal 1.1 wants to send a message to a list hosted by Exploder 1, Exploder 1 provides the exploder service to that terminal, i.e., sending a copy of the SIP message to each of the entries in the list.
A first problem with this procedure is that Exploder 1 must send two different INVITE requests to receivers within the same network. The INVITE requests addressed to Terminal 2.2 and list2@exploder2 follow the same path to the same network. This does not represent an optimal use of resources. Whilst the sending of only two different INVITEs may not represent a great problem, if the number of receivers in the destination network is high (e.g. several hundred), the required bandwidth and processing power may not be available.
Considering further the procedure illustrated in
A second problem which arises as a result of the conventional procedure is the long path of SIP signalling that may be created between edge endpoints. For example, when Terminal 4.2 has to send any SIP message relating to the established session, the SIP message must traverse Exploder 4, Exploder 3, Exploder 2, Exploder 1 until it is finally distributed to Terminal 1.1. This is necessary given that each exploder is, from the SIP perspective, a UA client or server associated with a particular “leg” of the session.
This creates a problem for real-time applications including (but not limited to) SIP. If a floor control mechanism is in place, and the floor control signalling follows the initial signalling path, Exploder 1 will be acting as the floor control manager. Terminals located “far away” in the signalling path will need to request the floor from the master exploder of the session (Exploder 1), and that request will take time to traverse the chain of exploders. As a consequence, users may not get a true real-time experience.
A third problem with the conventional procedure is now identified with reference to
It is noted that a single SIP message sent from an initiating terminal may contain multiple destination addresses, none of which are list addresses. Nevertheless, problems similar to those identified above might arise in this scenario, e.g. multiple messages being sent to the same destination network.
It will also be appreciated that the initiating message may be a SIP EXPLODE type message that carries another complete SIP message or a fragment of another SIP message (e.g., INVITE) together with a collection of destination addresses. The receiving exploder sends the encapsulated INVITE message to the various destination addresses to that user. Again, the problems identified above are likely to arise when using SIP EXPLODE messages in this way.
It is an object of the present invention to enable interdomain traffic to be transported efficiently with the minimum number of messages. The number of messages exchanged between two domains should not depend on the number of receivers. The real-time characteristics of the signalling must not be dependent on the number of exploders involved in a multiparty session and must not be negatively affected by the presence of several exploders in the session. There should be a mechanism to detect and avoid loops resulting from the concatenation of several lists.
According to a first aspect of the present invention there is provided a method of delivering a copy of a Session Initiation Protocol, SIP, message to each of a plurality of terminals in a multimedia communication system, the method comprising:
Typically, the SIP exploder is an application server which receives and sends SIP messages via a SIP proxy server. In the example of a 3G implementation of the invention, this SIP proxy server may be a Serving Call/Session Control Function (S-CSCF). The S-CSCF selectively forwards SIP messages to the exploder according to some pre-defined rule set. Of course, in some implementations, the exploder may receive SIP messages directly from the SIP terminal.
A destination address may be the address of a terminal user or an identification of a list of terminal users and/or other lists.
In the case that a SIP message contains in the destination field a list, the members of the list are identified by the exploder if the list belongs to the same domain as the exploder, and the message is sent to each of the identified members.
The message received at the first SIP exploder may be carried within a message of type SIP EXPLODE, in which case the destination addresses may be carried in the SIP EXPLODE message.
According to a second aspect of the present invention there is provided a method of delivering a copy of a Session Initiation Protocol, SIP, message to each of a plurality of terminals in a multimedia communication system, the method comprising:
According to a third aspect of the present invention there is provided a method of delivering a SIP message to a plurality of terminals in a multimedia communication system which uses Session Initiation Protocol (SIP), the method comprising:
In a particularly preferred embodiment of the invention, the first, second, and third aspects of the invention are implemented in a single system. Other embodiments may make use of only one or two of the aspects.
Other aspects of the invention are set out in the appended claims.
A new SIP message handling procedure is described here which aims to solve the aforementioned problems of the conventional procedures. The general principles of the solution are:
The concept of the SIP exploder has been introduced above. Lists are defined at exploders using various different mechanisms. For example, a user might log onto a web page and manage his lists interactively. Alternatively some specific protocol might be used. The IETF is working on a protocol, namely XCAP (XML Configuration Access Protocol), that provides the functionality to configure lists. 3GPP has defined an interface between Application Servers (the exploder is an Application Server) and the IMS terminals. This interface is named the Ut interface, and the protocol is referred to as XCAP. Yet another alternative is for network administrators to manage lists.
Exploder 1 receives the INVITE request (message 1 in
Exploder 2 receives the INVITE request (message 4) addressed to both the local terminal 2.2 and list2. It determines from message 4 that it is not the master exploder of the session, so it adopts the role of the slave exploder of the session. Exploder 2 then creates an INVITE request and sends it to Terminal 2.2 (message 5). Then Exploder 2 evaluates list2 and finds three entries: one of these is local (Terminal 2.1), the other two are not (Terminal3.4@exploder 3 and list3@exploder3). As Exploder 2 has adopted the role of the slave exploder of the session, it only creates a copy of the INVITE request for the local Terminal: it does not create copies of the INVITE request to entities that are located outside its own control. Rather, it sends a SIP REFER request [IETF: The Session Initiation Protocol (SIP) Refer Method, RFC 3515] back to Exploder 1 (message 7 in
Exploder 1 receives the REFER request and collects the addresses contained in the message into groups according to their local networks. In this example, both addresses in the REFER request (message 7) are part of the network controlled by Exploder 3. Therefore, Exploder 1 creates a new INVITE request addressed to Terminal3.4@exploder3 and list3@exploder3 and it sends it to Exploder 3 (message 8 in
Exploder 3 receives the INVITE request (message 8) and it sends a copy to its local Terminal 3.4 (message 9). It then evaluates the other destination, namely list3. List3 contains two entries, one local (Terminal 3.2), so Exploder 3 sends a copy of the INVITE request to Terminal 3.2 (message 10). The other entry in list3 points to Terminal4.2@exploder 4. As Exploder 3 is not the master exploder of the session, Exploder 3 does not send an INVITE to any resource located outside its own domain. Instead, Exploder 3 creates a REFER request (message 11 in
Exploder 1 receives the REFER request (message 11 in
Although in this example the originating SIP INVITE message contains only a single destination address (i.e. list1@exploder1), the message may contain multiple destination addresses. This option is used, for example, in so-called Push-to-Talk Over Cellular (POC) services.
In a variation of the procedure described above, SIP messages destined for multiple users may be carried within a SIP EXPLODE message type. The destination addresses are carried in the EXPLODE message. A S-CSCF node will automatically forward EXPLODE type messages to the attached exploder.
The solution presented here is worthy because the signalling path established is of a star configuration, with the master exploder at the centre of the star and the slave exploders around the periphery, rather than a chain. All subsequent signalling between any two terminals will need to traverse at most two exploders, independent of the total number of exploders in the session. The real-time characteristics of a session are not critically dependent upon the number of exploders in the session.
Exploder 1 is aware that it is acting as the master exploder for the session. It maintains a list of all the resources currently involved, directly (terminals and lists) or indirectly (resources in lists). Therefore, Exploder 1 is aware that list1@exploder1 has been already been expanded and each entry has been contacted and added to the session. Therefore, there is no need to expand list1@exploder1 again. The session setup procedure is considered to be complete, and no more actions are taken at Exploder 1 during this phase.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP04/50011 | 1/9/2004 | WO | 00 | 7/10/2006 |