Abstract:
A method for exchanging compression/decompression dictionaries, and a communications node, which comprises a client module issuing and receiving messages, a compression/decompression module for compression/decompression of messages issued and received by the client module, a first dictionary for use by the compression/decompression module, and a second dictionary for use by the compression/decompression module. When the client module determines a sequence based on which to exchange dictionaries with one or more peers (e.g. a P-CSCF), it creates the first dictionary comprising at least one prioritised type of message and sends the first dictionary to the compression/decompression module, which stores the first dictionary and further sends it to at least the peer node. Still based on said determined sequence, the client module further creates the second dictionary comprising at least one other type of message, sends the second dictionary to the compression/decompression module which stores it and further sends to a peer node.

Description:
TECHNICAL FIELD  
       [0001]    The present invention relates to a method and system for creating dictionaries for use in compression and decompression of messages. 
       BACKGROUND  
       [0002]    The Session Initiation Protocol (SIP) is an Internet Engineering Task Force (IETF) standard protocol for initiating an interactive user session that may involve multimedia elements such as video, voice, chat, gaming, and virtual reality. Like the Hypertext Transfer Protocol (HTTP) or the Simple Mail Transfer Protocol (SMTP), SIP works in the Application layer of the Open Systems Interconnection (OSI) communications model and can establish multimedia sessions or Internet telephony calls, modify, and terminate them. SIP can also be used to invite participants to unicast or multicast sessions that do not necessarily involve the initiator. Because SIP supports name mapping and redirecting services, it makes it possible for users to initiate and receive communications and services from various locations, and for networks to identify the users wherever they are. SIP is a request-response protocol, dealing with requests from clients and responses from servers. Participants are identified by SIP Uniform Resource Locators (URLs). Requests can be sent through any transport protocol, such as for example the User Datagram Protocol (UDP), the Stream Control Transmission Protocol (SCTP), or the Transport Control protocol (TCP). SIP determines the end system to be used for the session, the communication media and media parameters, and the called party&#39;s desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles the call transfer and termination. SIP is specified in IETF&#39;s Request for Comments (RFC) 3261, which is herein included by reference in its entirety. 
         [0003]    Nowadays, SIP has emerged as the protocol of choice for handling session setup in the IP Multimedia Subsystem (IMS). 
         [0004]    As SIP is employed for most session setup scenarios in IMS, it has been noticed that SIP signaling protocol is characterized by large message sizes, which results in increased processing demands on the nodes (e.g. terminals and servers) involved in the SIP sessions. For example, typical SIP messages range from a few hundred bytes up to a few thousand bytes. With the planned usage of SIP protocol in wireless handsets, as part of 2.5 G and 3 G cellular networks, where bandwidth over-the-air is scarce and call set-up time is critical, large message size become a problem. 
         [0005]    A partial solution to this drawback was provided by the use of SigComp (Signalling Compression). RFCs 3320 and 3321, which are also included herein in their entirety, specify a protocol on the IETF standards track that may be used to compress application layer protocols such as SIP. SigComp enables compression and decompression of messages sent across the networks, which have stringent bandwidth restrictions. SigComp may interface with the three main transport layer protocols, namely TCP, UDP and SCTP. One of the main drivers for the development of SigComp is its planned usage of text-based protocols like SIP in wireless handsets as part of 2.5 G and 3 G cellular networks. In such networks, the large SIP message size coupled with relatively low data rates across the radio interface results in significant transmission delays. SigComp provides a means to reduce this problem by offering robust, lossless compression of application messages. In SIP, SigComp is invoked and negotiated between the parties involved in the session (e.g. terminals and/or servers). The client may initiate the compression mechanism by requesting the use of SigComp through the inclusion of the extension header “comp=sigcomp” in the request message. SigComp implements a decompression virtual machine, which allows applications to dynamically select the compression algorithm of their choice. Thus, SigComp allows two peers to perform compression/decompression using any compression technique, provided that the decompressor is provided with the byte code needed to perform the decompression to recover the original message. This flexibility is achieved by virtue of the fact that the byte code for doing the decompression is transferred within the SigComp messages, hence allowing the originating party to practically choose any compression algorithm it sees fit, without causing any inter working problems. In that respect, the SigComp framework specifies a generic virtual decompressor machine. 
         [0006]    Upon establishment of a session with SigComp, one node (e.g. a terminal) sends a first message along with the byte code, which is binary program; this program indicates to the receiving terminal how it can decompress the compressed message using a SIP dictionary. The IETF RFC 3485, also included herein in its entirety, specifies the standard SIP dictionary. When sending a message, the SIP message content is compared with the SIP dictionary. If a match is found between a text string of the message and the dictionary, the message as sent does not include that string, but instead comprises a start address where, in the dictionary, the receiver can find the missing text string. The length of the string is also included so that the receiver terminal can recompose the compressed message using its own dictionary. 
         [0007]    Reference is now made to  FIG. 1  (Prior Art), which is high level representation of a SIP dictionary  100 . In such a dictionary, string (text) expressions E 1 -E n    102   i  used in SIP messages are inserted. Some or all of these expressions E i    102   i  may be complete SIP messages as well. They are used for replacing strings which are part of SIP messages, or SIP messages in their entirety, thus reducing the size of the transmitted message (Compressing the message). Typically, the size and number of expressions E i  is limited by the size of the memory allocated to the dictionary. 
         [0008]    Reference is now made to  FIG. 2  (Prior Art), which is a high level representation of a dictionary index  200 . When an expression is detected in SIP message to be transmitted to match an expression E i  of the dictionary, that expression of the SIP message is replaced within the message by the dictionary index  200  pointing to the expression within the dictionary. As the index size is much smaller than the replaced expression, the size of the transmitted message is reduced (the message is compressed). The index  200  may comprise the location  202  of the expression in the dictionary  100 , and the expression length  204 , thus providing sufficient information to the receiver side to retrieve the expression from its own dictionary  100  to be able to reconstruct (decompress) the original message. 
         [0009]    Reference is now further made to  FIG. 3  (Prior Art), which is a high level nodal operation and signal flow diagram of a SigComp compression/decompression scheme using a SIP static dictionary  100 . Shown in  FIG. 3  is a sender  302  (e.g. a terminal or a server) and a receiver  304  (e.g. another terminal or server), each one having a SigComp module  306  and  308  respectively and the same static SIP dictionary  100 . When the sender  302  desires to send a compressed message to the receiver  304  using SigComp, it first sends a message  310  via its SigComp module  306  that includes the byte code  311  to be used for decompression by the receiver  304 , which, upon receipt of the message  310 , stores the byte code, action  312 , and confirms the safe receipt of message  310  via a message confirm action  314 . Upon receipt of message  314 , the Sender  302  implicitly deducts that the byte code  311  was successfully received by Receiver  304 . Then only can the sender  302  send a compressed message, such as the compressed message  316 , to the receiver  304 , using its SigComp module  306 . For this purpose, the sender&#39;s SigComp module  306  uses the dictionary  100  to replace any expressions of the message  316  found to match expressions from the dictionary  100  with corresponding expression indexes as described hereinbefore, action  315 . The message  316  is then sent to the receiver  304  which, upon receipt of the message  316 , uses its own SigComp module  308  to decompress the message, action  318 , by retrieving from its own dictionary  100  the expressions that correspond to the indexes contained in the message  316 , thus reconstructing the original message. 
         [0010]    Due to the heavy signaling involved and SIP, 3 GPP (the 3 rd  Generation Partnership Project) IMS Release 5 standards mandates SigComp (Signaling Compression) as the compression/decompression protocol of choice for IMS. SIGCOMP stacks can be used in 3 G User terminals and all types of Call State Control Functions (CSCFs.) 
         [0011]    The major components of SigComp are:
   Compressor is the component that compresses the messages and uploads the byte code for the corresponding decompression algorithm to the decompressor as part of the SigComp message.   Decompressor (also called Universal Decompressor Virtual Machine, UDVM) provides a mechanism to uncompress messages by interpreting the corresponding byte code. The UDVM can be used to decompress the output of various compressors such as DEFLATE (defined in the IETF&#39;s RFC-1951).   State Handler retains information between received SigComp messages and thus, eliminates the need to send decompression instructions with each of the compressed message.   
 
         [0015]    SigComp is agnostic of compression algorithms, supports state handling for better compression ratio, is pluggable with any protocol stack and provides APIs for easy integration with any application. 
         [0016]    Besides static SIP dictionary defined in the IETF RFC 3585, SigComp can also use dynamic SIP dictionaries, which instead of being pre-defined as the static SIP dictionaries, they are rather updated each time a message is successfully decompressed. In such instances, the entire SIP decompressed message is copied in the dynamic dictionary in a round-robin manner, i.e. replacing the oldest message of the dictionary. In this manner, most recent decompressed messages are kept in the dictionary to serve as a basis for subsequent compression/decompressions. 
         [0017]    However, it has been proven though field trials that the current SigComp specifications have several shortcomings, which result into a compression ratio that is significantly less that what has been anticipated. For example, for some services such as Push-To-Talk (PTT), the latencies that resulted from the poor compression ratios achieved for message compression, compounded with the limited storage in end user devices to deal with large SIP messages, were unacceptable. 
         [0018]    Hypothesis to explain the reasons why the current SigComp specifications are not optimal are as follows:
   Dynamic compression does not work with non-reliable transport medium. This is due to the limited storage in end user devices and the requirements on this memory (size of memory) by the SigComp specification. In many devices, it is impossible to store more than 2 SIP message simultaneously. Since SIP messages can get out of order because of UDP, decompression failure occurs, as the state against which decompression should be performed had to be released due to shortage of memory. Eliminating this problem in its entirety will be costly, both in terms of performance &amp; efficiency. The key problem is that the dynamic compression is based on stateful compression, which does not work with non-reliable transports. As such, this is an overlook in the RFC.   due to the limited size of the memory in end user devices, data against which compression/decompression is taking place is constantly overwritten in a round robin fashion. The overwriting was deemed useful in improving compression according to the SigComp specification. This was based on the assumption that using current traffic information to compress future message would yield a better performance. This assumption misses two (2) key facts: first, it is true only for a monolithic protocol, which is not the case for SIP. Second, in SIP, the current traffic is rarely an indication of the future traffic.   
 
         [0021]    Conclusively, there is no predictability when it comes to performance, since it very much depends on the traffic type, and the performance cannot be optimized for a service such as PTT where latency to set up the session is the key performance indicator. 
         [0022]    The international publication WO 2005/011175 bears some relation with the field of the present invention. This publication teaches a system and method for compressing and compressing SIP messages using a tokenized binary protocol. Tokens represent message elements of internal data structures defining SIP messages. Such tokens may be assigned to message elements based on various design requirements. According to this publication, various kinds of dictionaries may be used such as for example static dictionaries which are never transmitted, or dynamic message dictionaries containing strings found only in specific messages. Furthermore, local dictionaries may contain additional text strings which are specific to a particular domain, or to a particular device. However, the international publication WO 2005/011175 stops short of suggesting creation of dictionaries as the one described in the present invention. 
         [0023]    The US patent application publication US2003/0233478 also bears some relation with the field of the present invention. This publication teaches a protocol message compression scheme for wireless communications system, wherein text messages are compressed for transmission. The method includes parsing text strings and encoding numerical values with a binary representation, analyzing the values of the text strings and populating a session specific codebook, which is initialized to empty, with partial strings from the values. This process is achieved as messages are processed for transmission, during real traffic. The method of compressing the message for transmission may also include parsing the message with a template and generating at least one substrings to be transmitted; parsing the at least one substring with entries in a session specific codebook and generating the first part of the compressed message; populating the session specific codebook with entries from unknown field values; parsing any unmatched substring with entries from a first static dictionary and generating a second part of the compressed message; parsing any still unmatched substring with entries from a second static dictionary and generating the third part; and combining the first part, the second part, and the third part of the compressed message for transmission. Nevertheless, the US patent application publication US2003/0233478 also stops short of suggesting the creation of dictionaries as the one described in the present invention. 
       SUMMARY  
       [0024]    Accordingly, it should be readily appreciated that in order to overcome the deficiencies and shortcomings of the existing solutions, it would be advantageous to have a method and system for effectively creating a User Specific Dictionary (USD) for use with the SigComp compression algorithm. The present invention provides such a method and system. 
         [0025]    A method for exchanging compression/decompression dictionaries, and a communications node, which comprises a client module issuing and receiving messages, a compression/decompression module for compression/decompression of messages issued and received by the client module, a first dictionary for use by the compression/decompression module, and a second dictionary for use by the compression/decompression module. When the client module determines a sequence based on which to exchange dictionaries with one or more peers (e.g. a P-CSCF), it creates the first dictionary comprising at least one prioritised type of message and sends the first dictionary to the compression/decompression module, which stores the first dictionary and further sends it to at least the peer node. Still based on said determined sequence, the client module further creates the second dictionary comprising at least one other type of message, sends the second dictionary to the compression/decompression module which stores it and further sends to a peer node. 
         [0026]    In one aspect, the present invention is a method for exchanging dictionaries used for compression and decompression of messages, the method comprising the steps of:
       a. determining a sequence based on which to send said dictionaries to one or more peers;   b. based on said determined sequence, creating a first dictionary comprising at least one prioritised type of message that is to be compressed;   c. sending the first dictionary to a SigComp module;   d. storing the first dictionary by the SigComp module;   e. sending the first dictionary by the SigComp module to at least a peer node;   f. based on said determined sequence, creating a second dictionary comprising at least one other type of message that is to be compressed;   g. sending the second dictionary to the SigComp module;   h. storing the second dictionary by the SigComp module; and   i. sending the second dictionary by the SigComp module to a peer node.       
 
         [0036]    In another aspect, the invention is a communications node comprising:
       a client module that issues and receives messages;   a compression/decompression module for compressing and decompressing the messages issued and received by the client module;   a first dictionary for use by the compression/decompression module in compression and decompression of the messages issued and received by the client module;   a second dictionary for use by the compression/decompression module in compression and decompression the messages issued and received by the client module;   wherein the client module determines a sequence based on which to exchange dictionaries with one or more peers and based on said determined sequence, creates the first dictionary comprising at least one prioritised type of message that is to be compressed and sends the first dictionary to the compression/decompression module, which stores the first dictionary and further sends it to at least a peer node;   further wherein the client module, based on said determined sequence, creates the second dictionary comprising at least one other type of message that is to be compressed, sends the second dictionary to the compression/decompression module which stores it and further sends to a peer node.       
 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS  
         [0043]    For a more detailed understanding of the invention, for further objects and advantages thereof, reference can now be made to the following description, taken in conjunction with the accompanying drawings, in which: 
           [0044]      FIG. 1  (Prior Art) is high level representation of a SIP dictionary; 
           [0045]      FIG. 2  (Prior Art) is a high level representation of a dictionary index; 
           [0046]      FIG. 3  (Prior Art) is a nodal operation and signal flow diagram of SigComp compression/decompression scheme using a Sip static dictionary; 
           [0047]      FIG. 4  is an exemplary nodal operation and signal flow diagram representative of a telecommunications network implementing a preferred embodiment of the present invention; and 
           [0048]      FIG. 5  is an exemplary high-level block diagram representative of a node implementing the preferred embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION  
       [0049]    The innovative teachings of the present invention will be described with particular reference to various exemplary embodiments. However, it should be understood that this class of embodiments provides only a few examples of the many advantageous uses of the innovative teachings of the invention. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed aspects of the present invention. Moreover, some statements may apply to some inventive features but not to others. In the drawings, like or similar elements are designated with identical reference numerals throughout the several views. 
         [0050]    The present invention provides a method and system for creating and using a User Specific Dictionary (USD) for use with SigComp, the USD being specific to a user and/or session and/or application, thus containing strings that are likely to be used by the user. In this manner, when applying SigComp compression to a message issued by the given application during the given session, the probability of matching parts of the messages with expressions from the USD are increased, and better compression ratios are achieved. 
         [0051]    In order to enhance the performance of SigComp, the present invention provides the USD, which allows every user to have a specific personalised dictionary that is uploaded to a peer (e.g. to a P-CSCF) and that is used by SigComp in lieu of, or in addition to, the prior art static and/or dynamic dictionary for compression/decompression purposes. It is to be noted that while the following exemplary implementation of the invention will be described with particular reference to SIP and SIP messages, the invention can be applied as well to other text-based signalling protocol. 
         [0052]    When a client uploads a USD to be used for compression with a peer in lieu of the default SIP dictionary, dynamic compression can be used concomitantly to the use of the USD, or suspended. Empirical results demonstrated that in some circumstances, a good USD yields better compression ratios than dynamic compression, thus leading to a much better performance, when it comes to compression ratios. The compression ratio depends to a large extent on the size of the USD, and the closeness of the content of the USD against the actual SIP traffic. Some results also demonstrated that for most, if not all applications, the session setup time is of critical importance. Equally important, was the size of presence-related traffic because of its significant size and unpredictability. Compression ratios had to be excellent for these traffic cases. 
         [0053]    As stated before, the USD is focused to optimize the performance of session start up and Presence traffic. Session set up in this case may be defined as including SIP messages needed for the session to be successfully established. The impacted SIP messages for session setup are thus the followings: 
         [0000]      INVITE, 1XX, 2XX, ACK. 
         [0054]    On the other hand, the impacted SIP messages for Presence are: 
         [0000]      PUBLISH, 2XX, NOTIFY, 2XX. 
         [0055]    The performance of the above traffic cases is measured as follows: 
         [0000]    
       
         
           
             
               Performance 
                
               
                   
               
                
               of 
                
               
                   
               
                
               session 
                
               
                   
               
                
               set 
                
               
                   
               
                
               up 
                
               
                   
               
                
               sequence 
             
             = 
             
               Uncompressed 
                
               
                   
               
                
               length 
                
               
                   
               
                
               of 
                
               
                   
               
                
               
                 
                   ( 
                   
                     INVITE 
                     + 
                     
                       1 
                        
                       XX 
                     
                     + 
                     
                       2 
                        
                       XX 
                     
                     + 
                     ACK 
                   
                   ) 
                 
                 / 
                 Compressed 
               
                
               
                   
               
                
               length 
                
               
                   
               
                
               of 
                
               
                   
               
                
               
                 ( 
                 
                   INVITE 
                   + 
                   
                     1 
                      
                     XX 
                   
                   + 
                   
                     2 
                      
                     XX 
                   
                   + 
                   ACK 
                 
                 ) 
               
             
           
         
       
     
         [0000]    where applicable during the session setup. 
         [0000]    
       
         
           
             
               Performance 
                
               
                   
               
                
               of 
                
               
                   
               
                
               presence 
             
             = 
             
               Uncompressed 
                
               
                   
               
                
               length 
                
               
                   
               
                
               of 
                
               
                   
               
                
               
                 ( 
                 
                   PUBLSIH 
                   + 
                   
                     2 
                      
                     XX 
                      
                     
                         
                     
                      
                     
                       ( 
                       PUBLISH 
                       ) 
                     
                   
                   + 
                   NOTIFY 
                   + 
                   
                     2 
                      
                     XX 
                      
                     
                         
                     
                      
                     
                       
                         ( 
                         NOTIFY 
                         ) 
                       
                       / 
                       Compressed 
                     
                      
                     
                         
                     
                      
                     length 
                      
                     
                         
                     
                      
                     of 
                      
                     
                         
                     
                      
                     
                       ( 
                       
                         PUBLISH 
                         + 
                         
                           2 
                            
                           XX 
                            
                           
                               
                           
                            
                           
                             ( 
                             PUBLISH 
                             ) 
                           
                         
                         + 
                         NOTIFY 
                         + 
                         
                           2 
                            
                           XX 
                            
                           
                               
                           
                            
                           
                             ( 
                             NOTIFY 
                             ) 
                           
                         
                       
                       ) 
                     
                   
                 
               
             
           
         
       
     
       USD Content 
       [0056]    Therefore, based on the above, the greater the length of the matched expressions (also called patterns) between the actual traffic and the USD, the better is the compression efficiency. Empirical results demonstrated that compression efficiency for session start-up sequence is optimized if the USD includes a complete INVITE and 2XX messages based on actual traffic for the concerned user. Similarly, empirical results demonstrated that compression efficiency for presence traffic is optimized if the USD includes a complete PUBLISH &amp; NOTIFY SIP messages. This implies that the USD content, for optimum performance from a compression efficiency point of view, should look as follows: 
         [0000]      USD optimized for session setup=INVITE+2 XX    
         [0000]      USD optimized for Presence=(NOTIFY+PUBLISH+2 XX  (PUBLISH)+2 XX  (NOTIFY)) 
         [0057]    As a typical SIP message is composed of a static part and a dynamic part that varies from every SIP session to another, the messages used to make up the USD as per the above should be composed from simulated real traffic, or real traffic, so that they reflect the user most recent contact list, and the behaviour of the application server the terminal is communicating with. Preferably, the USD should also be created immediately after power-up of a terminal or the launch of a given application, so that maximum compression can be achieved as soon as possible, such as for example when setting-up a new communication session. The USD may also be constantly updated from real traffic, in order to marginalize some of the dynamic aspects of the SIP messages, since they are now incorporated in the USD, thus improving the performance. 
         [0058]    Preferably, according to the invention, even though the USD is constantly updated during traffic, it is only submitted once to the SigComp module of the node (e.g. terminal or server) for transfer to the peer. Typically, this occurs every time the subscriber launches his client application, and registers for the first time. This USD may remain in effect until such time as the client closes the application and restarts it later where a new USD is sent again to the peer. 
         [0059]    The order of data entered in the USD may reflect the priority of the data. Hence, high priority data should be placed in first in the submitted USD. This may provide an advantage to the USD as it may take actually several SIP messages to transfer the entire USD to the peer for maximum compression efficiency. Transferring high priority data first allows that data to be used as soon as it is acknowledged by the peer. Furthermore, the typically limited size of memory available for storing the USD in terminals implies that for a large USD, parts of it may not be transferred, and hence cannot be used for compression. Thus, the low priority portions of the USD should be transferred at last. The SigComp module starts using any USD that has been confirmed by a peer for compressing/decompressing subsequent messages without waiting for the entire USD to be transmitted. 
         [0060]    When a client is being launched for the first time in a terminal or server, obviously there is no USD available to be submitted to SigComp. As such, there is a need to create the USD, which can be done using real traffic or simulated traffic. Once a USD is created, it may be regularly updated during traffic, so that once a user launches a client subsequent to the first time, the client submits the last saved USD to SigComp immediately at power-up registration. Even though it is typical for the client to submit the USD at power-up IMS registration, nothing prevents a client from submitting a USD later as long as it is included in the right message (for example, SigComp does not permit a USD to be included in some messages such as INVITE). 
         [0061]    According to the present invention, the USD for optimizing session start-up traffic is created independently from the USD for optimising presence traffic. They can also be submitted independently to SigComp, or alternatively they can be merged in a single big USD. For compression optimization purposes, it may be important to that the order in which various USDs or USD parts are submitted is maintained. The preferred structure of USD respecting priority is as follows: 
         [0000]      Possible USD structure=[INVITE, 2 XX , NOTIFY (complete NOTIFY), PUBLISH] 
         [0062]    The above structure implies that INVITE has the highest priority, as it is critical to session set-up, while PUBLISH has the lowest priority. As such, in order to allow the client flexibility in USD content based on the above structure, it is recommended that the client stores locally the content depicted above in 4 separate parts as follows: 
         [0000]      USD — 1=INVITE 
         [0000]      USD — 2=NOTIFY 
         [0000]      USD — 3=200 OK for INVITE 
         [0000]      USD — 4=PUBLISH 
         [0063]    The rationale for that choice is that the intent of the USD is to optimize the compression efficiency not only for session setup messages, but also for presence-related messages. For some types of memory used to store the USD, one can barely fit an INVITE and a NOTIFY, which are the most critical elements needed for compression, hence USD1 and USD2 are defined first to insure they can fit into the memory. For a greater memory size, one can afford to include more messages, and then order of the messages may be of reduced relevancy. It is to be understood that while in the present exemplary implementation the above-described message order may be preferred, other orders of the messages may be contemplated and found advantageous in other implementations as well. 
         [0064]    Reference is now made to  FIG. 4 , which is an exemplary nodal operation and signal flow diagram representative of a telecommunications network  400  implementing a preferred embodiment of the present invention. Shown in  FIG. 4  is first, a terminal  410  which comprises a client module  412 , such as for example a SIP client module capable of establishing, managing and terminating SIP communications on behalf of terminal  410 , and a SigComp module  414 , responsible for compression and a compression of messages on behalf of the client  412 . Initially, the terminal  410  may also comprise one or more static SIP dictionaries  407  and one or more dynamic SIP dictionaries  409  for use in compression and decompression of SIP messages. The terminal  410  communicates via appropriate communication interfaces and links with a Proxy Call State Control Function (P-CSCF)  416  responsible of providing network access and service support for the terminal  410 . The P-CSCF  416  may also comprises one or more static SIP dictionaries  407  and one or more dynamic SIP dictionaries  409 , which are to be used for compression and decompression of messages exchanged with terminal  410 . Finally, the P-CSCF  416  is connected to the IP Multimedia Subsystem (IMS) core network  417 , which connects to the Internet, and/or other networks. 
         [0065]    In  FIG. 4 , first, in action  420 , the client module  412  is launched on the terminal  410 . Such action may comprise the power-on of the terminal  410 , the start of the client application  412 , or alternatively any other triggering of the creation of the USD. The client module  412  issues a SIP REGISTER message  424 , action  422 , sent to the SigComp module  414 , which acts to compress the message using, for example, the static SIP dictionary, if any is present, as it is known in the art, and sends the compressed SIP REGISTER message to the P-CSCF  416  along with the byte code  423  (which is only sent if this was the first message sent from the SigComp module  414  to the P-CSCF  416  in the session), action  426 . The later decompresses the message  426  using the byte code  423  and the appropriate one of the dictionaries  407  and  409  (action not shown) and relays the message  426  to the IMS core network  417 , where the message is authorized and authenticated as known in the art. Upon successful registration of the terminal, the IMS core network  417  responds back to the P-CSCF  416  with a 200 OK message  428 , which is received and compressed by the P-CSCF  416  using the same dictionary as before. The compressed message  429  is decompressed by the SigComp module  414  and the 200 OK message is relayed in action  432  to the client  412 , thus confirming to the client  412  the successful registration with the P-CSCF  416 . 
         [0066]    At this point, the client module  412  determines the proper sequence (order) in which the various USDs are to be created and sent to the peer P-CSCF  416  to be used for compression and decompression of messages, action  433 . Part of action  433  may be not only determination of the sequence, but also of the number of USDs that are to be created. The client  412  should then act to create messages that are to be included in the determined and yet to be populated USDs. For that purpose, the client  412  creates SIP messages in a prioritized order defined for the USDs, i.e. INVITE message first, followed by a NOTIFY message, followed by a 200 OK message for INVITE, followed by a PUBLICH message. It is to be noted that while the above defined order has been deemed preferred in the exemplary scenario described by the present invention, other orders may be beneficial as well in the context of other applications. 
         [0067]    Based on this priority, the client  412  first acts in action  434  by creating a SIP INVITE message for a user from his contact list, and uses that INVITE message to create the first part of the USD, i.e. USD — 1. As the SIP INVITE message is created by the client module  412 , the message contains all the parameters specific to this user, and from this perspective, the USD — 1  437  is a user specific dictionary. It contains strings which are specific to the user, which augments the probabilities that these strings would be also found in subsequent SIP INVITE messages issued by the user, and used for dictionary-based compression, thus improving the compression efficiency. In action  436 , the client module  412  sends a SIP PUBLISH message containing USD — 1  437  to the SigComp module  414 , which acts to store the USD — 1  437 , action  439 , to compress the message and to send it further to the P-CSCF  416 , action  438 . Upon receipt of the USD — 1  437 , the P-CSCF  416  decompresses it and stores it locally, action  440 . The P-CSCF  416  then responds back with a 200 OK message, action  442  and respectively action  444  in order to confirm safe receipt of the USD — 1  437 . At this point, the SigComp module  414 , having stored the USD — 1  437  and the same USD — 1  437  being also saved by the P-CSCF  416 , SIP messages of any subsequent communications between the client module  412  and the P-CSCF  416  can be compressed using USD — 1  437 , in case the terminal  410  issues any subsequent SIP INVITE message. 
         [0068]    Next, the client module  412 , issues a SIP SUBSCRIBE message in action  445  in order to obtain presence status of contacts from its own contact list. The message reaches the SigComp module  414 , were it is compressed, and relayed in action  447  to the P-CSCF  416 . Confirmation of receipt of message  447  by the P-CSCF  416  is performed using 200 OK messages  451  and  453 . The later responds back with a compressed SIP NOTIFY message that contains the requested contact list status, action  448 . The SIP NOTIFY message is decompressed upon receipt by the SigComp module  414 , and relayed to the client module  412 , action  449 . The safe receipt of the message is confirmed by the client module  412  using 200 OK message of actions  450  and  452  respectively. The client module  412  being now provided with the NOTIFY message of action  449 , uses that message in action  456  to create the USD — 2 which content is the SIP NOTIFY message of action  449 . As the SIP NOTIFY message is destined to the client module  412 , it contains the parameters specific to this user, and from this perspective, the USD — 2  459  is a user specific dictionary. It contains strings which are specific to the user, which augments the probabilities that these strings would be also found in subsequent SIP NOTIFY messages destined to the user, and used for dictionary-based compression, thus improving the compression efficiency. In action  458 , the client module  412  issues a SIP PUBLISH message containing the USD — 2  459 , which is stored, action  461 , and compressed by the SigComp module  414 , and further relayed in action  460  to the P-CSCF  416 . Upon receipt of the message, the P-CSCF  416  decompresses the message, stores the USD — 2  459 , action  462 . This action may also comprise the concatenating of the USD — 2  459  with the USD — 1  440 , previously received in action  438 . Then, the P-CSCF  416  confirms safe receipt of the message in action  460  with 200 OK messages  464  and  466  respectively. At this point, the SigComp module  414 , having stored the USD — 2  459  and the same USD — 2  459  being also saved by the P-CSCF  416 , SIP messages of any subsequent communications between the client module  412  and the P-CSCF  416  can be compressed using USD — 2  459 , in case the P-CSCF  416  issues any subsequent SIP NOTIFY message. 
         [0069]    In order to create the next part of the USD, i.e. USD — 3 which should contain a 200 OK message for INVITE, the client module  412  issues a SIP INVITE message in action  468  to one of its contacts from its contact list. Unlike the SIP INVITE message of action  434  which was simulated and not sent, this SIP INVITE message is part of real traffic, as its purpose is to reach the contact&#39;s terminal and trigger a 200 OK response for use by the terminal  410  as it will be described herein. The SIP INVITE message reaches the SigComp module  414  where it is compressed (e.g. using the static SIP dictionary if any) and further sent in action  470  to the P-CSCF  416  which further relays it toward the contact terminal (action not shown). When the P-CSCF  416  receives from the contact&#39;s terminal a 200 OK message in return (action not shown), it replies back with the compressed version of the 200 OK message in action  472 , which is intercepted and decompressed by the SigComp module  414 , and further relayed to the client module  412 , action  474 . Being now provided with a real 200 OK message for INVITE, the client module  412  creates USD — 3 which content includes the 200 OK message received in action  474 , action  476 . As the SIP 200 OK message is destined to the client module  412 , it contains the parameters specific to this user, and from this perspective, the USD — 1  437  is a user specific dictionary. It contains strings which are specific to the user, which augments the probabilities that these strings would also be found in subsequent SIP 200 OK messages received by the user, and used for dictionary-based compression, thus improving the compression efficiency. Further in action  478 , the client module  412  sends the created USD — 3  477  using a SIP PUBLISH message, which is stored by the SigComp module  414  action  479 , and further compressed and sent in action  480  to the P-CSCF  416 . The later decompresses the message and stores the USD — 3  477 , action  482 . This action may also comprise the concatenating of the USD — 3  477  with the USD — 1  440  and USD — 2  459 , previously received in actions  438  and  460  respectively. Then, the P-CSCF  416  confirms safe receipt of the message  480  using 200 OK messages  484  and  486 . At this point, the SigComp module  414 , having stored the USD — 3  477  and the same USD — 3  477  being also saved by the P-CSCF  416 , SIP messages of any subsequent communications between the client module  412  and the P-CSCF  416  can be compressed using USD — 3  477 , in case the terminal  410  receives any subsequent SIP 200 OK message. 
         [0070]    Finally, the client module  412  creates a SIP PUBLISH message in action  490 , and uses that message to create the USD — 4 which content is the SIP PUBLISH message. As the SIP PUBLISH message is created by the client module  412 , the message contains the parameters specific to this user, and from this perspective, the USD — 4  489  is a user specific dictionary. It contains strings which are specific to the user, which augments the probabilities that these strings would be also found in subsequent SIP PUBLISH messages issued by the user, and can thus be used for dictionary-based compression, and as a result improving the compression efficiency. In action  491 , the client module  412  issues a SIP PUBLISH message for the SigComp module  414  containing the USD — 4  489 , which is stored, action  492 , and compressed by the SigComp module  414  (using any one of the dictionaries  407  and  409 ), and further relayed in action  493  to the P-CSCF  416 . Upon receipt of the message, the P-CSCF  416  decompresses the message, stores the USD — 4  489 , action  494 , and confirms safe receipt of the message with 200 OK messages  495  and  496  respectively. Action  494  may also comprise the concatenating of the USD — 4  489  with the USD — 1  440 , USD — 2  459 , and USD — 3  477 , previously received in actions  438 ,  460 , and  480  respectively. 
         [0071]    At this point, all four USDs are exchanged successfully between the client module  412  and the peer P-CSCF  416 , so that all of them can be used for any subsequent compression of a corresponding message: 
         [0000]      USD — 1=INVITE 
         [0000]      USD — 2=NOTIFY 
         [0000]      USD — 3=200 OK for INVITE 
         [0000]      USD — 4=PUBLISH 
         [0072]    Reference is now made to  FIG. 5 , which is an exemplary high-level block diagram representative of a node  500  implementing the preferred embodiment of the present invention. The node  500  may comprise a terminal  410  as the one described hereinbefore with relation to  FIG. 4 , a server, a P-CSCF (or any other type of CSCF), or any other type of node that may communicate using SigComp, in a manner similar or analogous to the one described in relation to  FIG. 4 . The node  500  comprises a client  412  such as the one previously described and which is responsible for establishing communication with other parties, such as for example with other terminals, servers, or CSCFs. The node  500  further comprises a SigComp module  414  which is responsible for the compression and decompression of messages issued by and destined to the client  412 . Finally, the node  500  comprises a USD  505 , which may be composed of a various USD parts, such as for example USD — 1  437 , USD — 2,  459 , USD — 3  477  and USD — 4  489 . The node  500  functions as described in relation to  FIG. 4 , previously described. For example, the node  500  may represent the terminal  410 , and the client  412  may act as described in  FIG. 4  in order to create messages that are to populate the various parts of the USD, which are to be used by the SigComp module  414  for compression and decompression purposes. Such USD parts are also sent by the node  500  two other parties with which the node  500  intends to communicate using SigComp. 
         [0073]    In a variant of the preferred embodiment of the invention, also illustrated in  FIG. 5 , the node  500  may run multiple applications (clients)  412 i, such as for example a Voice over IP application  412   1 , a PTT application  412   2 , and a file transfer application  412   3 . In such a configuration, each one of the application clients  412   i  has a corresponding USD  505   i , which may or may not be composed of multiple USD parts, wherein each one of the USD comprises expressions used by its corresponding client application  412   i . One or more SigComp modules  414  may perform the compression and decompression related actions on behalf of the application clients, using the USD that corresponds to each one of the application clients. In a first possible implementation, only one SigComp module  414  is present and performs the compression and decompression related actions on behalf of all application clients  412   i ., In a second possible implementation, there is one SigComp module  414   i  for each application client  412 i. 
         [0074]    Therefore, with the present invention it becomes possible to provide peer nodes, such as for example the terminal and the P-CSCF with USDs so that better compression is achieved. Furthermore, the USDs are exchanged between the peers as soon as they are created, preferably after initial terminal registration, so that they can be used as soon as they are needed. 
         [0075]    Based upon the foregoing, it should now be apparent to those of ordinary skills in the art that the present invention provides an advantageous solution for dictionary-based compression and decompression. Although the system and method of the present invention have been described in particular reference to SIP, those skilled in the art would readily appreciate that the present invention can be used with any type of text-based signaling protocol. It should be realized upon reference hereto that the innovative teachings contained herein are not necessarily limited thereto and may be implemented advantageously with any applicable protocol, such as for example the Session Description Protocol (SDP). It is believed that the operation and construction of the present invention will be apparent from the foregoing description. While the method and system shown and described have been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined by the claims set forth hereinbelow. 
         [0076]    Although several preferred embodiments of the method and system of the present invention have been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.