Patent Application
20090013078
This invention relates generally to communications systems, and in particular to optimizing signaling communications between signaling network entities in a communications environment.
Existing signaling protocols, such as Session Initiation Protocol (SIP), are used for creating session-oriented connections between two or more IP endpoints in an IP network. A session could be a simple two-way telephone call, a well elaborate collaborative multimedia conferencing application involving voice communications, file and video sharing, white boarding, along with many other types of applications. With SIP, many innovative network services become possible, such as voice-enriched e-commerce, web page click-to-dial, Instant Messaging with buddy lists, Push-to-Talk (PTT), voice-over-IP (VoIP), and IP Centrex services along with many other types of services. SIP has also been adopted by 3rd Generation Partnership Project (3GPP) and by 3GPP2 as the protocol of choice for signaling and call control in IP Multimedia Subsystem (IMS).
SIP has been developed as a Peer-to-Peer (P2P) protocol. It relies on the SIP end points, commonly called SIP User Agent (UA), to negotiate all the characteristics and parameters of a session using text-based SIP and Session Description Protocol (SDP) headers at session establishment phase. The consequence of this negotiation is a very large volume of information transfer between SIP entities. A typical SIP message ranges from few hundred bytes to more than two thousand bytes. While this may not be an issue in some wireline networks, it becomes a real challenge in wireless access networks. The bandwidth needed to transport SIP message increases, and so does the risk of transmission errors, memory, and power needed to process it. Furthermore, SIP text-based encoding makes SIP messages grow dramatically as soon as several extensions are used at the same time. This poses serious challenges to achieve cost effective, high performance carrier grade and differentiating user experience for real-time applications, such as mobile VoIP.
Due to the size and number of signaling messages required to establish a session, the use of SIP in certain applications may cause significant inefficiencies. For example, SIP is not optimized for wireless over the air environments. Large SIP messages have serious disadvantages when used in a wireless environment. For example, service behavior is too slow on relatively low-bandwidth links like the most common wireless signaling channels. If a SIP message is larger than the maximum size that a link layer can handle, the message will be fragmented. If one of the fragments is lost, the sender needs to retransmit the whole message, which degrades user experience. In addition to the length of SIP messages, SIP requires a multitude of messages to establish a session between the SIP endpoints.
To reduce the size and number of SIP messages required to establish a session, telecommunications industry has focused on compressing SIP messages for use over wireless links. For example, compressing SIP using SigComp described by RFC 3320, Text-based Compressing using Cache and Blank (TCCB) approach, or other mechanisms help reduce the size of SIP messages. But the SIP message body may remain too large, even after compression. To improve compression efficiency, a compression algorithm must be implemented in all network entities involved in a session establishment, such as UA and signaling proxy server, using SigComp. But this requirement may easily become a bottleneck and add to overall latency. The impact of having a compressor on a handset in terms of battery, processor, and memory is also unknown. Furthermore, due to the scalability and limited memory storage on a typical handset, maintaining a persistent state in the UA across call/sessions may not be a viable solution.
Accordingly, what is needed is a signaling framework for communications networks that optimizes the currently existing signaling protocols, such as SIP, to reduce the size and/or number of signaling messages exchanged between a user device and the network.
To reduce the size and/or number of messages required in a signaling communications protocol, such as SIP, embodiments of the invention optimize the signaling messages by reducing header information and/or the number of signaling messages exchanged. The optimization techniques may be used in a variety of applications, such as communications in a wireless environment.
In one embodiment, during the session registration between a communication device and a proxy server, the proxy server captures and retains certain header information that defines the characteristics of the session. For subsequent communications between the communication device and the proxy server, the communication device and proxy server can use a redacted version of a signaling protocol, for example, by eliminating the captured session information. For outbound communications, the proxy server receives a redacted signaling message from the communication device, reconstructs the signaling message, and forwards the reconstructed messaged to the destination. For inbound communications, the proxy server receives a signaling message, converts the message to a redacted signaling message, and forwards the redacted message to the communication device. In this way, the system uses the cached header information obtained during session establishment to reduce the information needed in the messages transmitted between the communication device and the proxy server. Consequently, the optimization is easily applicable to any session signaling protocols without any prior knowledge of the protocols.
The features and advantages described in the specification are not all inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the disclosed subject matter.
The figures depict various embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.
The communications terminal 110 has a SIP user agent (UA) 115 running for communications with the communications core network 120. The communications terminal 110 may be a personal computer (PC), a mobile phone, a wireless handhold, a personal digital assistant (PDA), or any other electronic computing device. For explanation purposes, only one communications terminal 110 and one communications core network 120 are depicted in
To communicate with the communications core network 120, the SIP UA 115 sends a signaling request message to a SIP proxy server 125 associated with the communications terminal 110, and receives a signaling response messages from the SIP proxy server 125. The signaling messages sent by or destined to the communications terminal 110 may be in a standard SIP message format or in a redacted signaling message format, described below.
The communications core network 120 comprises a SIP proxy server 125 and one or more SIP servers 130 to process SIP signaling messages. The SIP proxy server 125 is associated with one or more communications terminals 110 and forwards each signaling message sent by or destined to the communications terminal 110 associated with the SIP proxy server 125. The SIP servers 130 receive the SIP signaling messages forwarded from the SIP proxy server 125, further process signaling messages and send the messages to a recipient communication terminal 110. For example, in an IP Multimedia Subsystem (IMS) framework for delivering IP multimedia services to end users, the SIP proxy server 125 and SIP servers 130 provide several call/session control functionalities, collectively called Call Session Control Function (CSCF), to process SIP signaling messages in the IMS. A Proxy-CSCF (P-CSCF) is a SIP proxy server 125 that forwards each SIP signaling message send by or destined for an IMS communications terminal 110. Two SIP servers 130, Interrogating-CSCF (I-CSCF), and Serving-CSCF (S-CSCF), further process the SIP signaling messages forwarded from the P-CSCF.
In one embodiment, the SIP proxy server 125 receives a signaling request message in the redacted signaling message format from the SIP UA 115. The SIP proxy server 125 reconstructs a standard SIP request message from the redacted signaling message received from the SIP UA 115, and forwards the reconstructed standard SIP request message to the SIP servers 130. In another embodiment, the SIP proxy server 125 receives a signaling response message in standard SIP message format destined to the communications terminal 110. The SIP proxy server 125 redacts the received SIP response message to a signaling message in the redacted signaling message format, and forwards the redacted signaling message to the SIP UA 115.
The network 150 enables communications between the communications terminal 110 and the communications core network 120. In one embodiment, the network 150 uses standard communications technologies and/or protocols. Thus, the network 150 may include fixed links using technologies such as Ethernet, integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), or other fixed links technologies. The network 150 may also support mobile access using technologies such as Wideband Code Division Multiple Access (W-CDMA), CDMA200, Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), or similar technologies. Further, the network 150 may include wireless access using technologies, such as Wireless Local Area Network (W-LAN), Worldwide Interoperability for Microwave Access (WiMAX), or other wireless technologies.
Similarly, the networking protocols used on the network 150 may include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the User Datagram Protocol (UDP), the session initiation protocol (SIP), the session description protocol (SDP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), or any other suitable protocol. The data exchanged over the network 150 may be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), or any other suitable format. In addition, all or some of links may be encrypted using conventional encryption technologies, such as the secure sockets layer (SSL), Secure HTTP and/or virtual private networks (VPNs) or Internet Protocol security (IPsec). In another embodiment, the communications terminal 110 may use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
A typical SIP signaling message ranges from few hundred bytes to more than two thousand bytes. The bandwidth needed to transport SIP signaling messages increases, and so does the risk of transmission errors, memory, and power needed to process it, especially in wireless communications environment. To optimize the currently existing SIP signaling communications, various embodiments of the invention use the known information about the characteristics of the session to reduce the size of the SIP signaling message exchanged between the SIP UA 115 and the SIP proxy server 125 associated with the communications terminal 110. The known information about the characteristics of the session, nature of the session, and the additional data learned from the signaling messages exchanged during the SIP registration process are used to establish SIP session context data (SSC) identified by a context identification (ID). The relatively static data and parameters characterizing the session represented by the session context data are cached at the SIP proxy server 125. The SIP UA 115 and the SIP proxy server 125 use the cached SSC data to achieve the optimized signaling communications in terms of optimal use of network resources and call/session establishment delay reduction.
After connecting to the network 150, the communications terminal 110 obtains an IP address of the SIP proxy server 125 by the proxy server discovery process 200. All the SIP signaling messages sent by or destined for the communications terminal 110 traverses the SIP proxy server 125 associated with the communications terminal 110. The communications terminal 110 conventionally discovers the IP address of its associated SIP proxy server 125 with either Dynamic Host Configuration Protocol (DHCP), or it may be assigned an IP address for its associated SIP proxy server 125 using Packet Data Protocol (PDP) Context in the GPRS framework. Once the communications terminal 110 obtains the IP address of the SIP proxy server 125, the communications terminal 110 uses the same IP address to communicate with the SIP proxy server 125 as long as the communications terminal 110 does not initiate a new registration.
The communications terminal 110 registers with the communications core network 120 before the communications terminal 110 can establish any session. In one embodiment, the communications terminal 110 registration procedure uses SIP REGISTER request method. The communications terminal 110 completes the registration procedure in two rounds of registration process, the initial UA registration 205 and the authorized UA registration 215, as shown in
In one embodiment, in response to the received SIP REGISTER request from the SIP UA 115 during the initial UA registration 205, the SIP proxy server 125 captures the session context data components and stores 210 the session context data components in a local cache or other memory at the SIP proxy server 125. In response to the received SIP REGISTER request from the SIP UA 115 during the authorized UA registration 215, the SIP proxy server 125 captures and stores 210 additional session context data components in its local cache. With the cached SSC data components, the SIP proxy server 125 establishes the session context data via SSC data establishment 220, generates 225 a SSC context ID associated with the SSC data, and notifies 230 the SIP UA 115 of the generated SSC context ID.
In one embodiment, the context ID of the SSC data is encrypted for security purposes. An encrypted version of the context ID, called Integrity Key or IKEY, is used for authenticating the signaling messages and source of the signaling messages. The IKEY is generated by the communications terminal 110 and validated by the SIP proxy server 125 associated with the terminal 110. The input to an encryption algorithm includes the IP address, port numbers, the context ID of the SSC data and time in one embodiment. The result is a unique IKEY generated by the communications terminal 110. The SIP proxy server 125 calculates the server IKEY using the same input and same encryption algorithm. If the IKEYs generated by the communications terminal 110 and the SIP proxy server 125 match, the signaling message is considered authenticated. The context ID may be refreshed periodically after a period of time, such as Time To Live (TTL). Thus, the invention improves the level of security while reducing the size of the signaling message sent over the air between the communications terminal 110 and the SIP proxy server 125.
The session context data components captured during the session registration procedure include one or more SIP Header Fields, and/or session description parameters. In the example embodiments described below, the session description parameters comprise SDP Headers; however, other types of session description parameters may be used in other implementations.
In one embodiment, the session protocol information 305 comprises one or more SIP Header Fields from a list of SIP Header Fields 320, including Via, Require, Proxy-Require, Supported, Allow, Contact and Content-Type.
In one embodiment, the subscriber and user equipment information 310 comprises one or more SIP Header Fields and one or more SDP Headers 325, including M SDP Header for media type. The media type can be audio, video, text, image, or any other suitable type of media content.
In one embodiment, the session routing information 315 comprises one or more SIP Header Fields from a list of SIP Header Fields 330, including Max-Forwards, Route and P-Access-Network-Info. In one embodiment, session routing information 315 obtained through the SIP Header Fields 330, such as, Max-Forwards, Route and P-Access-Network-Info, are not pre-provisioned or predefined, but instead are collected on the fly from the SIP registration messages. In another embodiment, some session routing information 315 obtained through the SIP Header Fields 330, such as Max-Forwards, is stored in a system database as system configuration parameters. The SIP proxy server 125 may use the stored configuration parameters to construct/redact signaling messages.
One optimization of signaling communications achieved by an embodiment of the invention can be illustrated by examining the standard SIP REGISTER and INVITE messages examples. The following is an example of an initial REGISTER request sent by the IMS terminal 110 to the SIP proxy server 125 (P-CSCF) after the SIP proxy server discovery 200 in the IMS framework.
With the help of the SIP proxy server 125, the IMS terminal 110 sends the authenticated signaling message during the authorized UA registration 215 phase via the following SIP REGISTER message containing the authorization credentials. The message is routed from the proxy server 125 to the SIP servers I/S-CSCF 130 serving the IMS terminal 110.
Once the IMS terminal 110 is registered with the communications core network 120, the IMS terminal 110 initiates a SIP session using SIP INVITE method. The following is an example of SIP INVITE message.
The REGISTER and INVITE message examples above illustrate the level of redundancy within the messages and between session message exchanges. For instance, the IP address of an originator communications terminal 110 (i.e. 1080::8:800:200C:417A) of the SIP request is repeated in the Via and Contact headers as well as in the o (origin) and c (connection) fields of the SDP header. Furthermore, most of the information being transmitted is redundant with the content of the registration messages exchanged previously, and most of the content does not change during the whole registration period. Most of this known and relatively static information is included in every SIP message (SIP request and SIP response messages) exchanged between the proxy server 125 and the IMS terminal 110. This redundancy increases the load on the network as well as the risk of errors, which impacts the overall session setup latency.
The data learned from the SIP session registration procedure can be further illustrated with reference to the SIP header fields: Via, To, From, Cseq, Call-ID, and Max-Forwards. These fields constitute the six mandatory fields in every SIP signaling message.
The Via header is used to keep track of all the proxies a signaling request traversed. It provides only very little value when used between the proxy server 125 and the communications terminal 110. The proxy server 125 and the communications terminal 110 know each others' IP address during the proxy server discovery 210, and have security association established between them. The routing of the signaling messages can be done without the Via header. In one embodiment, all of the information contained in the Via header is cached by the proxy server 125 during the session registration procedure 205 and/or 215. The subsequent signaling messages sent between the communications terminal 110 and the proxy server 125 after the SSC data establishment do not include the Via header.
The Max-Forwards header is used in SIP signaling communications to avoid routing loops. Every SIP proxy server 125 that handles a signaling request decrements the Max-Forwards value by one. If it reaches to zero, the signaling request is discarded. In one embodiment, the value of the Max-Forwards header is set by the communications terminal 110 at the registration time, and is cached by the SIP proxy server 125 as a component of the SSC data established with the communications terminal 110. After the SSC data establishment, the subsequent signaling messages sent by the communications terminal 110 do not include the Max-Forwards header.
According to SIP specifications, the From, To, and Call-ID header fields transport end-to-end information. The network entities such as the SIP proxy server, and SIP servers, do not assert, inspect or take any action on the values of these headers. In particular, the From header field is not policed. The communications terminal 110 can use any value including a SIP user resource identification (URI) that does not belong to this communications terminal 110. Even if the information contained in these headers is accurate, it is generally redundant with the content of other SIP headers. Thus, in one embodiment of the invention, the signaling message in the redacted signaling message format does not make explicit use of the From, To, Call-ID header fields. The originator communications terminal 110, the universal resource locator (URL) of the originator, and the destination communications terminals 110 are implicitly indicated in front of the header associated with the method being used. For example, using the redacted signaling message format according to one embodiment of the invention, the first line of the INVITE message becomes:
The Cseq header field contains a sequence number and a method name. Cseq header field is used to match signaling requests and responses. One embodiment of the invention makes use of Cseq header field as a number value without the header name. The name of the method is also omitted if it is the same as the one in the start line of the message.
The following example illustrates this optimization. In the SIP message format, the partial INVITE message is:
With the redacted signaling message format, the above INVITE message becomes:
The absence of the method name after the 127 number in Cseq is interpreted by the SIP proxy server 125 as being the same as the name of the request which is the INVITE. The SIP proxy server 125 can add the method name (INVITE) to the Cseq header as part of the reconstruction of the SIP message before the SIP proxy server 125 sends the reconstructed SIP message out to other network entities.
The SIP P-Access-Network-Info header field describes the type of access network being used and the cell ID. In one embodiment of the invention, the type of access being used is cached as a session context data component so that the SIP UA 115 does not have to include this header field in the subsequent signaling messages. If the SIP UA 115 changes the type of access network, the SIP UA 115 re-registers, and the session context data is then updated. If the change of access network does not result in a new SIP registration, the SIP UA 115 may use the “UPDATE” method defined in RFC 3311 or a similar method to report any changes in the session context data.
The SIP Supported header field (Supported: path) is used for the SIP UA 115 to implement new extensions with new headers and message bodies without the need for the intermediate servers, such as the SIP proxy server 125, to understand them. The use of the Support header allows the SIP UA 115 to inform the network 150 and the other SIP UAs 115 of which extensions and features it supports. To avoid the need for including the Supported header field in the INVITE message, one embodiment of the invention includes all the extensions that the SIP UA 115 supports and wants to advertise to the network 150 and other SIP UAs 115 in the Supported header of the REGISTER message as follows:
When a SIP session dialog is being established, the SIP UA 115 lists all the names of the SIP extensions it wants to use for that dialog in the Require header field. To avoid transmitting the Require header field with each message after the establishment of the session context data, in one embodiment, the SIP UA 115 indicates during the session registration time, in the Require header, all the names of the SIP extensions it wants to use.
As mentioned above, with SIP, new headers and message bodies can be added without the need for the proxy server 125 to support them. The Proxy-Require header is included in the session request message to indicate the need for the proxy server 125 to activate, understand and interpret the feature provided with this header. These indicated features are mandatory capabilities that the SIP proxy server 125 must support. For example, as required by the 3GPP/3GPP2 standards, the SIP proxy server 125 is required to support the security association established with the SIP UA 125. As the support for security agreement or association is a must for all mobile SIP UAs 115, in one embodiment of the invention, the SIP proxy server 125 supports the security agreement or association by default. Hence there is no need to specify such support explicitly with each message. In another embodiment, this capability as well as others required from the proxy server 125 can be specified once for all in the registration phase and the SIP proxy server 125 caches it as a component of the session context data established with the SIP UA 115. The subsequent signaling messages sent by the communications terminal 110 after the SSC data establishment do not include the Proxy-Require header.
The Contact header field contains the SIP uniform resource identifier (URI) or IP address that can be used to send SIP requests to the SIP UA 115. Practically, the IMS communications terminal 110 is not aware of its URI. The Contact header contains the IP address of the IMS communications terminal 110 and the port number bound to the security association and used for receiving SIP messages. This information is redundant and is provided to the SIP proxy server 125 at the registration phase. There is no need to send it with each message exchange after the session context data is established and the established security association remains active. If the IP address of the SIP UA 115 changes, the SIP UA 115 sends an update message to the SIP proxy server 125 to update its cached session context data.
Using one or more of the above techniques may significantly reduce the size of the SIP messages (especially the INVITE message) exchanged between the terminal 115 and the proxy server 125 after the session context data establishment 220 is completed. One embodiment of the invention further reduces the signaling message size by handling the other SIP headers fields appropriately, as demonstrated in the following, which continues with the example of the INVITE message described above.
In addition to the option tags used with Require and Supported to indicate the SIP extensions supported or desired, SIP can also be extended by defining other methods. In a SIP session dialog, the SIP UAs 115 need to know the methods supported by each other. Each UA 115 lists all the methods it supports in the Allow header field and sends the listed methods to the destination communications terminal 110. For example, as the IMS communications terminal 110 connecting to an IMS core network 120 must be IMS compliant, the IMS communications terminal 110 is expected to support some extensions, at least the basic ones that are part of the call flow (like INVITE, BYE, ACK, PRACK, etc.). The methods required for supporting VoIP are considered as supported by all the registered and authorized SIP UAs 115 by default.
In another embodiment, the SIP UA 115 may advertise all the methods it supports during the session registration with the IMS core network 120. The SIP proxy server 125, caches that information as part of the session context data. Hence, the SIP UA 115 does not have to include the Allow header in any message exchange after the establishment of the session context data. The following is an example of the Allow header field:
The P-Preferred-Identity header field is another extension to SIP specified in the RFC 3325 (Privacy Extensions to SIP for Asserted Identity within Trusted Networks). This header is used by the communications terminal 110 to indicate which one of the communications terminal's 110 identities should be used for the current session. In one embodiment, if the communications terminal 110 has multiple IDs that are used to select services, the preferred identity to use can simply be included in front of the INVITE header in the following manner:
The session description parameter, such as the SDP Header, that is used to describe and negotiate the characteristics of the session contributes significantly to the overall size of the INVITE message. To know when the quality of service (QoS) requirements indicated in the SDP header of the INVITE are met, the SIP UAs 115 exchange SDP messages and send UPDATE messages to inform each others that the QoS conditions are met in their respective access network. This conventional SIP method leads to the additional exchange of messages with long SDP headers. To avoid this situation, in one embodiment of the invention, the communications terminals 110 at the registration time inform the network 150 of their capabilities, such as the codecs (audio, video, audio and video, etc.) they can support for multimedia data. The communications terminals 110 then let the network 150 negotiate and pick the best characteristics of the session and inform the communications terminal 110.
In one embodiment, the network sets up and provides an appropriate level of QoS for a particular session depending, for example, on the capabilities of the device, the subscriber profile, the type of application, and/or the conditions of the network. This provides a capacity-quality tradeoff that would be optimal for both the communications network services providers and their customers. Eventually, the customers are charged according to the level of QoS being provided. Hence, with this embodiment, the QoS precondition is assumed at the start of the session and the SIP UA 115 does not need to explicitly state it in session establishment messages. Avoiding the QoS negotiation between the SIP UA 115 and the network 150 at each call setup and sending UPDATE messages between the two communications terminals 110 involved in the session reduces the number of messages as well as the time required to set up the session.
The message bodies in SIP, such as the SDP body, are transmitted end-to-end. The SIP proxy server 125 and the other SIP entities do not need to parse the message body to route the message. To illustrate the optimization that may be achieved using the session context data, the following Table I identifies some key headers in the SDP body in the IMS framework and how they are used with the redacted SIP format, according to one embodiment of the invention.
Using the optimization techniques described above, the INVITE message used in the redacted signaling message format is the following, in accordance with an embodiment of the invention:
In another embodiment, to clarify further the INVITE message in the redacted signaling message format from the one in standard SIP message format, a new method called INITIATE is used for initiating a session instead of the INVITE message. The following is an example of an INITIATE message, which may be equivalent to the standard SIP INVITE message:
The From and To are implicit in this message: From=alice@ims1.net=Preferred Identity, and To=bob@ims2.net. An encrypted context ID, i.e. IKEY, is used as a pointer or index to the session context data for the SIP proxy server 125 to retrieve the agreed upon parameters.
With the session context data establishment, general signaling messages such as INVITE, SUBCRIB, NOTIFY, PRACK, OK, UPDATE, and the like can be optimized with reduced signaling message size and number of signaling messages needed for the signaling communications. The SIP UA 115 sends signaling request messages in the redacted signaling message format to the SIP proxy server 125. The redacted signaling request message has less SIP header fields than required by the SIP message format. In response to the received redacted signaling request message, the SIP proxy server 125 reconstructs the equivalent standard SIP request message from the redacted signaling message by retrieving at least some of the missing header fields from the cached SSC. The SSC data are stored in the SIP proxy server 125 and can be retrieved using a context ID that is shared by the proxy server 125 and the SIP UA 115 that owns the SSC.
For outbound communications, the UA 115 sends 400 a redacted message to the proxy server 125, where the redacted message is created using one or more of the optimization techniques described above. In response to the received redacted signaling message from the communications terminal 110, the SIP proxy server 125 reconstructs 410 a standard SIP message from the redacted signaling message by adding any missing SIP header fields or other data to the redacted signaling message. The proxy server 125 obtains this information by checking 405 the SSC cache stored at the proxy server 125.
The examples from the previous discussion can be used to illustrate how the SIP proxy server 125 reconstructs a standard SIP INVITE message from the redacted INITIATE message. First, the SIP proxy server 125 changes the method name from INITIATE to INVITE and then adds the SIP version information retrieved from the cached SSC data. The SIP proxy server 125 adds the Max-Forwards header as defined by a communications service provider or by the communications terminal 110 at the registration time. The SIP proxy server 125 adds the Via, Route, P-Access-Network-Info, From, To, Contact and Allow headers using the SSC data. The SIP proxy server 125 uses the information in the INITIATE message to reconstruct the Privacy, Call-ID and Cseq headers. The Require and Supported header fields can be added by the SIP proxy server 125 if not assumed as part of the signaling communications. The SIP proxy server 125 populates the P-Asserted-Identity header field with a valid SIP registered Public User Identity of the communications terminal 110 following the procedures specified in RFC 3325. The value could be the same as the one in the INITIATE message (i.e., alice@ims1.net) or any other valid and registered public user ID corresponding to the PrIdIndex specified in the INITIATE message. The SIP proxy server 125 adds the Record-Route and P-Charging-Vector header fields as specified in standard SIP procedures. The Proxy-Require and Security-Verify are local to the SIP proxy server 125 and are not added to the INVITE message. The SIP proxy server 125 adds the Content-Type and Content-Length headers as well as the SDP header constructed based on the type of media session the communications terminal 110 wants to setup and the QoS and Policies defined by the communications service provider. In addition to the SDP header M, the SIP proxy server 125 adds the following SDP headers: V, O, S, C, T, B, and A into the reconstructed SIP message. The SIP proxy server 125 forwards the reconstructed SIP message to the SIP servers 130.
In one embodiment of the invention, when the SIP proxy server 125 receives the INITIATE message request, it validates the QoS requirements with the Policies defined by the communications service provider to make sure that there is enough resource to establish the session. The SIP proxy server 125 reserves the required resources temporarily for the duration of the call setup. If the destined communications terminal 110 accepts the call, the resources are confirmed and attributed to the session; otherwise, the resources are released. This mechanism avoids the need for exchanging multiple signaling messages between the communications terminals 110 and between the communications terminal 110 and the SIP proxy server 125.
In response to the received standard SIP message from the SIP servers 130, for an inbound message, the SIP proxy server 125 redacts the standard SIP message to a redacted signaling message by deleting the appropriate SIP header fields using the appropriate information in the cached SSC data. In one embodiment, the SIP proxy server 125 compares each of the header field of the standard SIP message with the cached SSC data and deletes the header field if it matches the cached SSC data. The SIP proxy server 125 then forwards the redacted signaling message to the communications terminal 110. Consequently, the size as well the structure of the SSC data remains flexible.
Embodiments of the invention are designed to optimize a signaling protocol, such as SIP, by reducing the signaling message size without requiring compression and/or by reducing the number of signaling messages needed to exchange to set up a session, as described above. One benefit of this optimization is to simplify the function logic at the communications terminals 110. The communications terminal 110 does not need to maintain a session state or implement a compressor/decompressor. For example, such optimization reserves power resource and prolongs the battery life of mobile/wireless communications devices.
In another embodiment, the current existing signaling communications protocols, such as SIP, are supported. During the SIP registration phase, the communications terminal 110 indicates its desire to support the redacted signaling message format for session setup and for potentially signaling communications after the session context data establishment. If the SIP proxy server 125 supports the redacted signaling messages, the SIP proxy server 125 collects the necessary session context data components to establish the session context data, creates a unique context ID, and shares it with the communications terminal 110. If the SIP proxy server 125 does not support the redacted signaling messages, the SIP proxy server 125 sends a notification to the SIP UA 115 and continues using the standard SIP messages for the signaling communications.
The foregoing description of the embodiments of the invention has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above teachings.
Some portions of above description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof. In addition, the terms used to describe various quantities, data values, and computations are understood to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or the like, refer to the action and processes of a computer system or similar electronic computing device, which manipulates and transforms data represented as physical (electronic) quantities within the computer system memories or registers or other such information storage, transmission, or display devices. Embodiments of the invention may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, application specific integrated circuits (ASICs), or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. Furthermore, the computers referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
Embodiments of the invention may also relate to a computer data signal embodied in a carrier wave, where the computer data signal includes any embodiment of a computer program product or other data combination described herein. The computer data signal is a product that is presented in a tangible medium and modulated or otherwise encoded in a carrier wave transmitted according to any suitable transmission method.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may also be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the invention are not described with reference to any particular programming language. It is appreciated that a variety of programming languages may be used to implement various embodiments of the invention as described herein, and any references to specific languages are provided for disclosure of enablement and best mode of embodiments of the invention.
Finally, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
