WO2010047229A1 - 通信システムおよび通信装置 - Google Patents

通信システムおよび通信装置 Download PDF

Info

Publication number
WO2010047229A1
WO2010047229A1 PCT/JP2009/067497 JP2009067497W WO2010047229A1 WO 2010047229 A1 WO2010047229 A1 WO 2010047229A1 JP 2009067497 W JP2009067497 W JP 2009067497W WO 2010047229 A1 WO2010047229 A1 WO 2010047229A1
Authority
WO
WIPO (PCT)
Prior art keywords
sip
parameter
message
list
client
Prior art date
Application number
PCT/JP2009/067497
Other languages
English (en)
French (fr)
Inventor
清水 桂一
井上 雅広
Original Assignee
三菱電機株式会社
株式会社エヌ・ティ・ティ・ドコモ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社, 株式会社エヌ・ティ・ティ・ドコモ filed Critical 三菱電機株式会社
Priority to US13/122,737 priority Critical patent/US20110196976A1/en
Priority to CN200980141680.6A priority patent/CN102197635A/zh
Priority to JP2010534770A priority patent/JPWO2010047229A1/ja
Priority to EP09821927.2A priority patent/EP2343874A4/en
Publication of WO2010047229A1 publication Critical patent/WO2010047229A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04Protocols for data compression, e.g. ROHC
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1101Session protocols
    • H04L65/1104Session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/2876Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/565Conversion or adaptation of application format or content
    • H04L67/5651Reducing the amount or size of exchanged application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/1036Signalling gateways at the edge

Definitions

  • the present invention relates to a communication system and a communication apparatus having a function of compressing / decompressing a SIP message used for SIP (Session Initiation Protocol) signaling.
  • SIP Session Initiation Protocol
  • SIP is a protocol for establishing multimedia sessions such as audio and video, and is specified in IETF (The Internet Engineering Task Force) RFC2543. Since messages used in SIP are defined in text as in HTTP, messages are generally large in size, and when used in a low bandwidth communication environment, problems such as increased call setup time and wasted bandwidth are problematic. Become. Therefore, in IETF, RFC 3320 defines SIP signaling compression technology SigComp (Signaling Compression). In SigComp, a compression / decompression algorithm is not defined, but a compression algorithm such as Deflate is used implicitly. These compression algorithms perform binary compression that removes redundancy in bits included in each packet.
  • Patent Document 1 when communication devices that terminate a SIP create and transmit a short text message in which redundant parameters are deleted when transmitting a SIP message, and when receiving a SIP message, A technique for improving the compression efficiency by specifying the text syntax (parameter) deleted on the transmission side and restoring the SIP message is described.
  • Patent Document 1 can be applied only to communication devices (SIP client, SIP proxy, etc.) that know the meaning of SIP. There is a problem that a possible section is limited between communication devices that terminate SIP, and a communication device that does not know the meaning of SIP cannot compress the SIP message.
  • the SIP proxy that knows the meaning of SIP does not compress the SIP message, and the node that does not know the meaning of SIP compresses it.
  • the PDCP Packet Data Convergence Protocol
  • 3GPP 3rd Generation Partnership Project
  • the SIP message compression is also performed by this node (base station controller). This is because the SIP message can be compressed more efficiently by the base station controller.
  • the technique described in Patent Document 1 cannot be applied to such a case, and the compression efficiency cannot be improved.
  • the present invention has been made in view of the above, and an object of the present invention is to obtain a communication system that performs high-efficiency compression of SIP in a node that does not know the meaning of SIP, and a communication device that constitutes the communication system.
  • the present invention includes a SIP client, a proxy of the SIP client, and a node that is located between the SIP client and the proxy and relays a received SIP message.
  • the node when relaying a SIP message addressed to the SIP client, the node replaces management information set in a specific parameter of the received SIP message with an ID that uniquely indicates the content, and When storing the ID and the management information in association with each other, while relaying a SIP message which is a SIP message transmitted from the SIP client and whose specific parameter is set to the same ID as the stored ID, Replace the ID with the management information associated with it
  • the SIP client stores the parameter and the ID in association with each other, and the SIP message including the same parameter as the stored parameter Is transmitted, an ID associated therewith is set for the parameter.
  • the node that performs the process of replacing the setting value of each parameter and the ID need only recognize the parameter that needs to be replaced with the ID among the parameters included in the SIP message. There is an effect that the SIP message can be compressed without knowing the meaning of (the set value for the parameter in the SIP message).
  • FIG. 1 is a diagram illustrating a configuration example of a wireless communication system according to the present invention.
  • FIG. 2 is a sequence diagram illustrating an example of normal SIP signaling (which does not compress SIP messages).
  • FIG. 3 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the first embodiment.
  • FIG. 4 is a diagram illustrating a method for managing compression target parameters in a node that compresses a SIP message.
  • FIG. 5 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the second embodiment.
  • FIG. 6 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the third embodiment.
  • FIG. 7 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the fourth embodiment.
  • FIG. 8 is a diagram illustrating a method for managing compression target parameters.
  • FIG. 1 is a diagram illustrating a configuration example of a wireless communication system according to the present invention.
  • the wireless communication system according to the present embodiment has a voice communication function, SIP clients (SIP Client) 1-1 and 1-2 serving as SIP termination units, and SIP are installed, and SIP clients 1-1 and 1- Proxy nodes 2-1 and 2-2 that are the opposite nodes of node 2 and a node 3-1 that does not terminate the SIP but compresses and decompresses the received SIP message (restoring the SIP message before being compressed) And the proxy 2-1 and 2-2 are connected to the SIP network.
  • the node 3-1 is located between the SIP client 1-1 and the proxy 2-1, and relays various messages (signals) including SIP messages.
  • the node 3-2 is located between the SIP client 1-2 and the proxy 2-2, and relays various messages (signals) including SIP messages.
  • Each SIP client and each node perform wireless communication.
  • Each node can accommodate a plurality of SIP clients.
  • FIG. 2 is a sequence diagram showing normal SIP signaling (without SIP message compression) (call setting by SIP), and as an example, a sequence when normal SIP signaling is executed in the wireless communication system of FIG. Is shown.
  • SIP signaling that does not compress the SIP message
  • the nodes 3-1 and 3-2 shown in FIG. 1 simply relay the SIP message, so in FIG. 2, the nodes 3-1 and 3-2 Description of operation is omitted.
  • a client who wants to start communication (SIP client 1-1 in this example) first sends an INVITE message to the client (SIP client 1-2) of the communication partner. Issue (send).
  • This INVITE message reaches the other party via the proxy 2-1 and the proxy 2-2, but information about the proxy is added when relayed by each proxy.
  • a Via parameter (corresponding to “Via: ⁇ ” shown in the figure) included in the header of the INVITE message and a Record-Route parameter (“Record-Route: ⁇ shown in the figure; Ir; URL information of the proxy 2-1 (corresponding to “Proxy2-1_URL” shown in the figure).
  • Each proxy transmits a 100 Trying message to the SIP client or proxy that is the source of the INVITE message after forwarding (relaying) the INVITE message.
  • the SIP client 1-2 that has received the INVITE message transmits a 180 Ringing message (hereinafter simply referred to as “Ringing message”) as a response message.
  • Ringing message a 180 Ringing message
  • the values of the Via parameter and the Record-Route parameter included in the received INVITE message are set as they are.
  • this Ringing message is transferred (relayed) after deleting some information set in the Via parameter in each proxy. For example, in the proxy 2-2, “Via: Proxy2-2_URL” is deleted. That is, each proxy deletes its own URL information from the information set in the Via parameter when transferring the Ringing message.
  • the SIP client 1-1 receives the OK message and transmits an ACK message as a response message thereof
  • the Record parameter (“Record: XXX” shown in FIG. ”) Is set after rearranging the URL information (list of URL information) of each proxy set in the Record-Route parameter of the received OK message so that the arrangement order is reversed.
  • Each proxy deletes its own URL information from the information set in the Record parameter of the received ACK message when transferring the ACK message.
  • the SIP client that issues the BYE message sets the Record-Route parameter of the INVITE message received when communication is started.
  • the URL information of each proxy that has been set is set in the Record parameter of the BYE message as it is (without rearranging the URL information).
  • each proxy appends its own URL information to the information set in the Via parameter of the received BYE message, and deletes its own URL information from the information set in the Record parameter. To do.
  • the information set in the Via parameter of the received message and the Record-Route parameter are set in the same manner as when the OK message is returned to the INVITE message.
  • Information is set as it is in the Via parameter and Record-Route parameter of the OK message.
  • the BYE message does not include the Record-Route parameter, only the Via parameter is actually set.
  • each proxy deletes its own URL information from the information set in the Via parameter, as in the case of transferring an OK message for the INVITE message.
  • the sequence in which the SIP client 1-2 on the receiving side of the INVITE message issues a BYE message is shown, but the same applies to the case where the SIP client 1-1 issues a BYE message. That is, when the SIP client 1-1 issues a BYE message, the information (URL information of each proxy) set in the Record-Route parameter of the OK message for the INVITE message is set in the Record parameter.
  • the Via parameter, Record-Route parameter, and Record parameter included in each SIP message have a correlation. This correlation can be considered implicitly known by the SIP client that terminates the SIP protocol.
  • the number of proxies that relay SIP messages between SIP clients 1-1 and 1-2 (proxy that understands and forwards the contents of SIP messages) is two. But in reality there are many more proxies. As can be seen from the above description, when many proxies exist between SIP clients, the information set in the Via parameter or the like increases, and the size of the SIP message increases.
  • the SIP message transmission path includes a wireless section, such as when the SIP client is a wireless communication terminal, it is desirable to compress the SIP message for effective use of wireless resources.
  • FIG. 3 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the first embodiment.
  • SIP signaling is started from the SIP client 1-1 illustrated in FIG. An example of doing this is shown.
  • FIG. 3 pays particular attention to the SIP client 1-2, proxy 2-2, and node 3-2 that are located in the section in which the SIP message compression / decompression control is executed in the wireless communication system of the present embodiment. The sequence executed between them is shown.
  • the proxy 2-2 sends an INVITE message to the SIP client 1-2 via the node 3-2.
  • the Via parameter and Record-- in the header of this message are sent.
  • a URL list is set in the Route parameter.
  • the URL list is transmission path management information, and is a list in which URLs of all proxies (which may include SIP clients) on the SIP message path are arranged in the order on the path.
  • the node 3-2 transmits the SIP message to the SIP client 1-2, the node 3-2 assigns a unique ID to the various URL lists, and the information (URL list) set in the Via parameter in the header and The information (URL list) set in the Record-Route parameter is replaced with the ID, and the various URL lists and the replaced ID are stored in association with each other.
  • the SIP client 1-2 when receiving the INVITE message, stores the ID included in the INVITE message in association with the parameter in which it is set.
  • An ID assigned to each URL list is assigned to each value of the URL list. That is, the ID does not indicate the type of the URL list, but uniquely indicates the contents of the URL list.
  • the SIP client 1-2 when the SIP client 1-2 transmits a Ringing message, an OK message, and a BYE message, the Via parameter, Record-Route parameter, and Record parameter are set in the headers thereof. These values are the same as the URL list set in the header of the received INVITE message. Therefore, the SIP client 1-2 sets the ID notified by the INVITE message in the header of each transmission message and transmits it to the proxy 2-2 via the node 3-2.
  • the node 3-2 When receiving a SIP message from the SIP client 1-2, the node 3-2 first stores a URL list corresponding to the ID (information uniquely indicating the URL list) set in the header of the node 3-2. Specify from the URL list. Next, the ID set in the header of the received message is replaced with the specified URL list, and then transferred to the proxy 2-2.
  • each of the URL list set in the Via parameter in the header and the URL list set in the Record-Route parameter are ID #. 1, ID # 3.
  • the SIP client 1-2 transmits a SIP message (Ringing message, OK message, BYE message)
  • the Via parameter and Record-Route parameter in those headers are replaced with the originally set URL list.
  • ID # 1 and ID # 3 corresponding to these are set.
  • the proxy 3 replaces the ID set in the Via parameter and Record-Route parameter in the header with the corresponding URL list. To -2.
  • FIG. 4 is a diagram showing a method for managing compression target parameters (via parameters, Record-Route parameters, Record parameters) in the node 3-2.
  • the node 3-2 manages the URL list set in the compression target parameter in the SIP message received from the proxy 2-2 and the ID in association with each other.
  • the node 3-2 manages a plurality of SIP clients such as the SIP client 1-2a, the SIP client 1-2b, and the SIP client 1-2c, but manages an ID for each SIP client. do not have to. That is, it is not necessary to recognize which client has transmitted the URL list corresponding to the ID and which client should be transmitted.
  • each SIP client manages session information and ID in association with each other. The same applies to the compression target parameter and its ID management method in the node 3-1 and the SIP client connected thereto.
  • the node that relays the SIP message between the SIP client and the proxy is set in the header of the message to be relayed when relaying the SIP message to the SIP client.
  • the content of each parameter is replaced with an ID that uniquely indicates the information. did.
  • the ID is replaced with the corresponding content and relayed.
  • FIG. 5 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the second embodiment.
  • SIP signaling is started from the SIP client 1-1 illustrated in FIG. An example of doing this is shown.
  • FIG. 5 particularly focuses on the SIP client 1-1, proxy 2-1 and node 3-1, which are located in the section in which the SIP message compression / decompression control is executed in the wireless communication system of the present embodiment. The sequence executed between them is shown.
  • the signaling control operation in the radio communication system of the present embodiment will be described with reference to FIG. 1 and FIG. Note that a description of the same parts as those in Embodiment 1 is omitted.
  • the proxy 2-1 sends a 100 Trying message (hereinafter simply referred to as “Trying message”) to the SIP client 1-1 via the node 3-1.
  • a Ringing message and an OK message are transmitted.
  • URL lists are set as Via parameters and Record-Route parameters in the headers of these SIP messages.
  • the correlation of the Via parameter and Record-Route parameter included in each SIP message can be implicitly known to the SIP client that terminates the SIP protocol.
  • the node 3-1 transmits a SIP message to the SIP client 1-1
  • the node 3-1 assigns IDs to the various URL lists, and replaces the URL lists set in the Via parameter and the Record-Route parameter with this ID.
  • These various URL lists are stored in association with IDs.
  • the SIP client 1-1 receives the SIP message, it stores the ID set in the Via parameter and Record-Route parameter in the header. Note that the IDs assigned to the various URL lists are assigned to the respective values (URLs) of the URL list as in the first embodiment.
  • the SIP client 1-1 when the SIP client 1-1 receives an OK message and transmits an ACK message as a response thereto, the Via parameter and Record parameter in the header are set, but the setting value for the Via parameter is the previous value. This is the same value (URL list) set in the Via parameter of the received OK message. Further, the setting value for the Record parameter is obtained by rearranging the URL list set in the Record-Route parameter of the received OK message so that the order of arrangement is reversed. Therefore, the SIP client 1-1 sets the ID set in the Via parameter in the header of the received OK message to the Via parameter in the header of the ACK message and also records- in the header of the received OK message.
  • a code or character string: “Reverse” is described as an example in FIG.
  • the node 3-1 When receiving a message from the SIP client 1-1, the node 3-1 first specifies a URL list corresponding to each ID set in the header from the stored URL list. Next, for the Via parameter of the received message, the ID set therein is replaced with the corresponding URL list in the specified URL list, while for the Record parameter, the ID set therein is changed to the above-mentioned ID list. After the corresponding URL list in the identified URL list is replaced with a reverse one (rearranged so that the order is reversed), it is transferred to the proxy 2-1.
  • the SIP client 1-1 transmits the ID set in the Via parameter of the received BYE message as the Via parameter of the OK message.
  • the node 3-1 replaces the ID set in the Via parameter of the received OK message with the corresponding setting value (URL list), and then transfers it to the proxy 2-1.
  • the SIP client receives the first SIP message including a certain URL list, and the URL obtained by reversing the received URL list as a response message.
  • the node transmitting the first SIP message uses the URL list as an ID.
  • the first SIP message replaced with is sent to the SIP client, and the SIP client that has received the first SIP message sets the ID included in the received message to the second SIP message and corresponds to the ID.
  • the instruction information for reversing the URL list to be set is set and this second SIP message is set.
  • the node that received the message modifies the URL list corresponding to the ID included in the ID according to the instruction contents, sets the obtained URL list after modification in place of the ID, and transfers it to the opposing proxy. It was. As a result, even if the URL list set in a certain SIP message and its response message is not the same and the URL list is reversed, the redundancy parameter (URL list) is compressed to improve the SIP compression efficiency. Can be improved.
  • control operation shown in the present embodiment can be performed (combined) in parallel with the control operation shown in the first embodiment.
  • FIG. 6 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the third embodiment.
  • SIP signaling is started from the SIP client 1-1 illustrated in FIG. An example of doing this is shown.
  • FIG. 6 pays particular attention to the SIP client 1-2, proxy 2-2, and node 3-2 that are located in the section in which the SIP message compression / decompression control is executed in the wireless communication system of the present embodiment. The sequence executed between them is shown.
  • a signaling control operation in the radio communication system according to the present embodiment will be described with reference to FIGS. Note that a description of the same parts as those in Embodiment 1 or 2 is omitted.
  • the Via parameter is based on the Via parameter (URL list) received in the INVITE message, and the top URL of the list is transmitted.
  • the SIP client 1-2 responds to the Via parameter of the Ringing message with the ID notified in the INVITE message (the ID set in the Via parameter of the INVITE message) and the URL list corresponding to the ID.
  • the node 3-2 When the node 3-2 receives the Ringing message, the node 3-2 first identifies the URL list stored in the URL list corresponding to the ID set in the Via parameter. Next, the ID set in the Via parameter of the received Ringing message is replaced with the specified URL list, and further, at the top of the replaced URL list according to the instruction information and the additional character string included in the received message. After adding the character string, transfer to the proxy 2-2.
  • the URL list included in the received SIP message is set by using the method as described above, and a sequence of transmitting a SIP message with a predetermined character string added to the URL list is executed.
  • the redundant parameter can be deleted, and the SIP compression efficiency can be improved.
  • the SIP client is obtained by receiving the first SIP message including a URL list and adding a character string to the first URL in the received URL list.
  • the node that transmits the first SIP message transmits the first SIP message in which the URL list is replaced with the ID to the SIP client,
  • the SIP client that has received the first SIP message sets the ID included in the received message in the second SIP message and adds a character string to the first URL in the URL list corresponding to the ID.
  • the instruction information and the character string to be added are set, and the second SIP message is received.
  • control operation shown in the present embodiment can be performed (combined) in parallel with the control operation shown in the first and second embodiments.
  • FIG. 7 is a sequence diagram illustrating an example of SIP signaling in the wireless communication system according to the fourth embodiment.
  • SIP signaling is started from the SIP client 1-1 illustrated in FIG. An example of doing this is shown.
  • FIG. 7 pays particular attention to the SIP client 1-2, proxy 2-2, and node 3-2 that are located in the section where the compression / decompression control of the SIP message is performed in the wireless communication system of the present embodiment. The sequence executed between them is shown.
  • the description of the same parts as those in Embodiments 1, 2, or 3 is omitted.
  • the URL list set in the Via parameter of the INVITE message transmitted between SIP clients is the SIP client that becomes the sender (SIP client 1 in the example of FIG. 2). -1), which is set at the end of the list.
  • the node 3-2 and the SIP client 1-2 reduce the memory capacity required by the node 3-2 by executing the following operation.
  • the Via parameter is set.
  • the URL list excluding the URL of the SIP client serving as the sender (hereinafter referred to as “sender URL”) is replaced with an ID (“# 1 + SIP / 2.0 / TCP as an example in FIG. 7).
  • all of the set information (URL list) is replaced with an ID as in the first embodiment.
  • the URL list replaced with the ID is stored in association with the ID.
  • the description of the Record-Route parameter is omitted.
  • the SIP client 1-2 when receiving the INVITE message, stores the ID and URL character string (sender URL) included therein.
  • the ID and URL character string stored when the INVITE message is received are set in the Via parameter.
  • the ID stored in the Record-Route parameter of the INVITE message (the ID set in the Record-Route parameter of the INVITE message) is set in the Record-Route parameter of the Ringing message.
  • the operation of the SIP client 1-2 is basically the same as that of the SIP client 1-2 described in the first embodiment.
  • the information set in the Via parameter and Record-Route parameter of the received INVITE message is stored, and when the Ringing message is transmitted, the Via parameter and Record-Route parameter are stored in the Via parameter.
  • the information stored when the INVITE message is received is set.
  • the node 3-2 When the node 3-2 receives the Ringing message from the SIP client 1-2, the node 3-2 first stores the URL list corresponding to the ID set in the Via parameter and Record-Route parameter in the header. Specify from the URL list. Next, the ID set in the header of the received message is replaced with the specified URL list, and for the Via parameter, the sender URL set in the Via parameter of the received Ringing message is set, and then the proxy 2 To -2.
  • a node that receives the SIP message when a SIP message is compressed and transferred, a node that receives the SIP message receives a URL list excluding the sender URL for the Via parameter included therein. Is replaced with an ID, and other information (Record-Route parameter) is transferred after the entire URL list is replaced with an ID.
  • the part representing the SIP client the URL of the SIP client
  • the node that compresses the SIP message manages only the URL of the proxy to be relayed.
  • a character string of a URL list to be managed is common to a plurality of accommodated SIP clients.
  • the amount of URL list information managed by the node is reduced, and the memory capacity required by the node can be reduced.
  • the URL character string not only a character string indicating an actual URL but also a character string expressing a protocol such as SIP / 2.0 / TCP, an option such as a branch can be described. That is, a URL character string that is a target when compressing a Via parameter (replaced with an ID) means a general character string including a URL.
  • the redundant parameter can be deleted, and the SIP compression efficiency can be improved.
  • control operation shown in the present embodiment is a modification of the first embodiment, but can be performed (combined) in parallel with the control operation shown in the second or third embodiment. It is.
  • each node that compresses a SIP message manages a URL list that is information to be compressed (via parameter, Record-Route parameter, Record parameter) by the method shown in FIG.
  • a different management method will be described.
  • a SIP compression unit that executes compression processing of a SIP message performs unified management of a URL list and an ID.
  • the base station control device is not aware of the SIP protocol, as a result, there is a part that manages a connection corresponding to the SIP client in a 1: 1 ratio. For example, a part that manages radio resources for each user.
  • the wireless connection information is managed in correspondence with the SIP client.
  • the URL list can be managed in association with the wireless connection information, and the ID only needs to be uniquely assigned in one SIP client. For example, as shown in FIG.
  • the node 3-2 manages the wireless connection management information (shown in the figure) with the already held SIP clients (SIP clients 1-2a, 1-2b, 1-2c).
  • SIP clients 1-2a, 1-2b, 1-2c the already held SIP clients
  • a plurality of IDs having the same value can be used.
  • the correspondence list between the URL list and the ID becomes very large.
  • the method for managing the URL list and the ID without being aware of the connection (session) shown in FIG. There arises a problem that it takes time to search and specify information (URL list) corresponding to the ID in the SIP message.
  • the management method shown in FIG. 8 is used, the target URL list can be specified in a short time as long as the wireless connection can be specified, so that the above problem can be prevented from occurring.
  • the SIP Via, Record-Route, and Record parameters have been described as examples. However, if the usage method is the same as these parameters, the compression can be performed by the same method.
  • an example of a wireless communication system has been described. However, a wired communication system may be used, and the same effect as that of the wireless communication system is achieved.
  • the communication system according to the present invention is useful for realizing SIP signaling with a reduced amount of information transmission.
  • a node that does not terminate the SIP protocol such as a base station controller or a base station, It is suitable for performing compression and expansion to achieve higher compression efficiency.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

 本発明は、SIPクライアント1-2、プロキシ2-2およびノード3-2を含んだ通信システムであって、ノード3-2は、SIPクライアント1-2宛のSIPメッセージを中継する場合、パラメータに設定されている管理情報をIDに置き換え、またIDと管理情報を関連付けて記憶し、記憶したIDが設定されたSIPメッセージを中継する場合、IDをこれに関連付けられた管理情報に置き換え、SIPクライアント1-2は、受信したSIPメッセージのパラメータにIDが設定されている場合、パラメータとIDを関連付けて記憶し、また、記憶したパラメータを含んだSIPメッセージを送信する場合、パラメータに対して、これに関連付けられたIDを設定する。

Description

通信システムおよび通信装置
 本発明は、SIP(Session Initiation Protocol)シグナリングに使用するSIPメッセージを圧縮・伸張する機能を有する通信システムおよび通信装置に関する。
 SIPは音声や映像などマルチメディアのセッションを確立するためのプロトコルであり、IETF(The Internet Engineering Task Force)RFC2543で規定されている。SIPで使用するメッセージはHTTPと同じくテキストで規定されているため、メッセージは一般的に大きなサイズになり、帯域の小さな通信環境で使用する場合、呼設定時間の増大や帯域の浪費などが問題となる。そのため、IETFではRFC3320でSIPシグナリングの圧縮技術SigComp(Signaling Compression)を規定している。このSigCompでは圧縮解凍アルゴリズムは規定されていないが、暗黙的にはDeflateなどの圧縮アルゴリズムが利用される。これら圧縮アルゴリズムは各パケットに含まれるビットにおける冗長性を除去するバイナリ圧縮を行うものである。
 また、下記特許文献1には、SIPを終端する通信装置同士が、SIPメッセージを送信する際に冗長なパラメータを削除した短いテキストメッセージを作成・送信し、また、SIPメッセージを受信する際には送信側で削除されたテキスト構文(パラメータ)を特定してSIPメッセージを復元することにより圧縮効率を向上させる手法が記載されている。
特許第4044845号公報
 しかしながら、上記特許文献1に記載の技術は、SIPの意味を知っている通信装置(SIPクライアント(SIP Client)、SIPプロキシ(SIP Proxy)など)に対してのみ適用が可能である、すなわち、適用可能な区間がSIPを終端する通信装置間に限られ、SIPの意味を知らない通信装置ではSIPメッセージを圧縮することができない、という問題があった。
 通信システムでは、SIPの意味を知っているSIPプロキシでSIPメッセージの圧縮を行わず、SIPの意味を知らないノードで圧縮を行うケースも想定される。たとえば、3GPP(3rd Generation Partnership Project)で規定されたPDCP(Packet Data Convergence Protocol)機能は、IPヘッダなどの圧縮を行う機能であるが、この機能はSIPを終端しない基地局制御装置に実装される。このためSIPメッセージ圧縮もこのノード(基地局制御装置)で行う可能性がある。SIPメッセージの圧縮も基地局制御装置で行うようにした方が効率的な圧縮が可能となるからである。しかしながら、上記特許文献1に記載の技術は、この様なケースには適用できず、圧縮効率を向上させることができない。
 本発明は、上記に鑑みてなされたものであって、SIPの意味を知らないノードにおいて、SIPの高効率な圧縮を行う通信システムおよびこれを構成する通信装置を得ることを目的とする。
 上述した課題を解決し、目的を達成するために、本発明は、SIPクライアント、当該SIPクライアントのプロキシ、および当該SIPクライアントと当該プロキシの間に位置し、受信したSIPメッセージを中継するノードを含んだ通信システムであって、前記ノードは、前記SIPクライアント宛のSIPメッセージを中継する場合、受信したSIPメッセージの特定のパラメータに設定されている管理情報をその内容を一意に示すIDに置き換え、また当該IDと当該管理情報とを関連付けて記憶し、一方、前記SIPクライアントから送信されたSIPメッセージでありかつその特定のパラメータに前記記憶したIDと同じIDが設定されたSIPメッセージを中継する場合、当該IDをこれに関連付けられた管理情報に置き換え、前記SIPクライアントは、受信したSIPメッセージの特定のパラメータに前記IDが設定されている場合、当該パラメータと当該IDとを関連付けて記憶し、また、当該記憶したパラメータと同じパラメータを含んだSIPメッセージを送信する場合、当該パラメータに対して、これに関連付けられたIDを設定することを特徴とする。
 この発明によれば、各パラメータの設定値とIDとを置き換える処理を実施するノードは、SIPメッセージに含まれるパラメータのうち、IDに置き換える必要があるパラメータのみを認識していればよく、SIPプロトコル(SIPメッセージ内のパラメータへの設定値)の意味を知らなくてもSIPメッセージを圧縮することができる、という効果を奏する。
図1は、本発明にかかる無線通信システムの構成例を示す図である。 図2は、通常の(SIPメッセージの圧縮を行わない)SIPシグナリングの一例を示すシーケンス図である。 図3は、実施の形態1の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図である。 図4は、SIPメッセージの圧縮を行うノードにおける圧縮対象パラメータの管理方法を示す図である。 図5は、実施の形態2の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図である。 図6は、実施の形態3の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図である。 図7は、実施の形態4の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図である。 図8は、圧縮対象パラメータの管理方法を示す図である。
 以下に、本発明にかかる通信システムおよび通信装置の実施の形態を図面に基づいて詳細に説明する。なお、この実施の形態によりこの発明が限定されるものではない。
実施の形態1.
 図1は、本発明にかかる無線通信システムの構成例を示す図である。本実施の形態の無線通信システムは、音声通信機能を有し、SIP終端部となるSIPクライアント(SIP Client)1-1および1-2と、SIPを実装し、SIPクライアント1-1および1-2の対向ノードとなるプロキシ(Proxy)2-1および2-2と、SIPを終端しないが、受信したSIPメッセージの圧縮および伸張(圧縮される前のSIPメッセージの復元)を行うノード3-1および3-2と、を含み、プロキシ2-1および2-2はSIPネットワークに接続されている。また、ノード3-1は、SIPクライアント1-1とプロキシ2-1との間に位置し、SIPメッセージを含む各種メッセージ(信号)を中継する。ノード3-2は、SIPクライアント1-2とプロキシ2-2との間に位置し、SIPメッセージを含む各種メッセージ(信号)を中継する。なお、各SIPクライアントと各ノードは無線通信を行う。各ノードは、複数のSIPクライアントを収容可能である。
 ここでまず、本実施の形態の無線通信システムにおける特徴的な動作を説明する前に、その前提となるSIPシグナリング制御動作を図1および図2に基づいて説明する。図2は、通常の(SIPメッセージの圧縮を行わない)SIPシグナリング(SIPによる呼設定)を示すシーケンス図であり、一例として、図1の無線通信システムにおいて通常のSIPシグナリングを実行する場合のシーケンスを示している。なお、SIPメッセージの圧縮を行わないSIPシグナリングでは、図1に示したノード3-1および3-2はSIPメッセージを単に中継するだけなので、図2においては、ノード3-1および3-2の動作の記載を省略している。
 図2に示したように、SIPによる呼設定では、まず通信開始を希望するクライアント(この例ではSIPクライアント1-1)がINVITEメッセージを通信相手先のクライアント(SIPクライアント1-2)に向けて発行(送信)する。このINVITEメッセージはプロキシ2-1およびプロキシ2-2を介して相手側に到達するが、各プロキシで中継される際にプロキシに関する情報が追記される。たとえば、プロキシ2-1では、INVITEメッセージのヘッダに含まれるViaパラメータ(図示した「Via:○○○○」に相当)およびRecord-Routeパラメータ(図示した「Record-Route:○○○○;Ir」に相当)に対してプロキシ2-1のURL情報(図示した「Proxy2-1_URL」に相当)が追記される。また、各プロキシは、INVITEメッセージ転送(中継)後、このINVITEメッセージの送信元のSIPクライアントまたはプロキシに対して100 Tryingメッセージを送信する。
 上記INVITEメッセージを受信したSIPクライアント1-2は、応答メッセージとして180 Ringingメッセージ(以下、単に「Ringingメッセージ」と記載する)を送信する。その際、受信したINVITEメッセージに含まれていたViaパラメータおよびRecord-Routeパラメータの値をそのまま設定する。また、このRingingメッセージは、各プロキシにおいてViaパラメータに設定された一部の情報が削除された上で転送(中継)される。たとえばプロキシ2-2では「Via:Proxy2-2_URL」が削除される。すなわち、各プロキシは、Ringingメッセージを転送する際に、そのViaパラメータに設定されている情報から自身のURL情報を削除する。
 同様に、上記RingingメッセージにつづいてSIPクライアント1-2からSIPクライアント1-1へ送信された200 OKメッセージ(以下、単に「OKメッセージ」と記載する)を転送する場合にも、各プロキシは、受信したOKメッセージのViaパラメータに設定されている情報から自身のURL情報を削除する。
 また、SIPクライアント1-1が、上記OKメッセージを受信し、その応答メッセージとしてACKメッセージを送信する場合、それに含まれるパラメータの一つであるRecordパラメータ(図示した「Record:○○○○;Ir」に相当)には、受信したOKメッセージのRecord-Routeパラメータに設定されていた各プロキシのURL情報(URL情報のリスト)を、その並び順が逆になるように並べ替えた上で設定する。そして、各プロキシは、ACKメッセージを転送する場合、受信したACKメッセージのRecordパラメータに設定されている情報から自身のURL情報を削除する。
 さらに、SIPクライアント間で通信を切断する場合、BYEメッセージを発行するSIPクライアント(図2の例ではSIPクライアント1-2)は、通信を開始する際に受信したINVITEメッセージのRecord-Routeパラメータに設定されていた各プロキシのURL情報を、そのまま(各URL情報を並べ替えることなく)BYEメッセージのRecordパラメータに設定する。各プロキシは、BYEメッセージを転送する場合、受信したBYEメッセージのViaパラメータに設定されている情報に自身のURL情報を追記し、またRecordパラメータに設定されている情報からは自身のURL情報を削除する。
 BYEメッセージに対してOKメッセージを返送する場合、上記INVITEメッセージに対してOKメッセージを返送する場合と同様に、受信したメッセージのViaパラメータに設定されていた情報およびRecord-Routeパラメータに設定されていた情報を、そのままOKメッセージのViaパラメータおよびRecord-Routeパラメータに設定する。ただし、BYEメッセージにはRecord-Routeパラメータが含まれないため、実際には、Viaパラメータのみを設定する。各プロキシは、OKメッセージを転送する場合、上記INVITEメッセージに対するOKメッセージを転送する場合と同様に、Viaパラメータに設定されている情報から自身のURL情報を削除する。
 なお、図2の例では、INVITEメッセージの受信側であるSIPクライアント1-2がBYEメッセージを発行するシーケンスを示したが、SIPクライアント1-1がBYEメッセージを発行する場合についても同様である。すなわち、SIPクライアント1-1がBYEメッセージを発行する場合、そのRecordパラメータには、上記INVITEメッセージに対するOKメッセージのRecord-Routeパラメータに設定されていた情報(各プロキシのURL情報)を設定する。
 以上のように、各SIPメッセージに含まれるViaパラメータ、Record-Routeパラメータ、Recordパラメータには相関関係がある。そして、この相関関係は、SIPプロトコルを終端するSIPクライアントでは暗黙的に既知とみなすことができる。
 また、図1に示した無線通信システムでは、SIPクライアント1-1と1-2との間でSIPメッセージを中継するプロキシ(SIPメッセージの内容を理解して転送するプロキシ)の数は2であるが、実際には、さらに多くのプロキシが存在する。上記説明からも分かるように、SIPクライアント間に多くのプロキシが存在する場合には、Viaパラメータなどに設定される情報が増加し、SIPメッセージのサイズが大きくなる。SIPクライアントが無線通信端末である場合など、SIPメッセージの伝送経路に無線区間が含まれる場合には、SIPメッセージを圧縮して無線リソースの有効利用を図ることが望まれる。
 つづいて、本実施の形態の無線通信システムにおけるシグナリング制御動作を図1および図3に基づいて説明する。図3は、実施の形態1の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図であり、上記図2で示したシーケンスと同様に、図1に示したSIPクライアント1-1からSIPシグナリングを開始する場合の例を示している。なお、図3は、特に、本実施の形態の無線通信システムにおいてSIPメッセージの圧縮・伸張制御を実行する区間に位置しているSIPクライアント1-2、プロキシ2-2およびノード3-2に注目し、これらの間で実行されるシーケンスを示している。
 図3に示したように、通信開始後、プロキシ2-2は、ノード3-2経由でSIPクライアント1-2に対してINVITEメッセージを送信するが、このメッセージのヘッダ内のViaパラメータおよびRecord-RouteパラメータにはURLリストが設定されている。ここで、URLリストとは、伝送経路の管理情報であり、SIPメッセージの経路上の全てのプロキシ(SIPクライアントを含む場合もある)のURLを経路上の順番に従って並べたリストである。上述したとおり、各SIPメッセージに含まれるViaパラメータ、Record-Routeパラメータには相関関係があり、この相関関係は、SIPプロトコルを終端するSIPクライアントでは暗黙的に既知とみなすことができる。
 そのため、ノード3-2は、SIPメッセージをSIPクライアント1-2へ送信する際、この各種URLリストに対して独自のIDを割り当て、ヘッダ内のViaパラメータに設定されている情報(URLリスト)およびRecord-Routeパラメータに設定されている情報(URLリスト)を上記IDに置き換えるとともに、これらの各種URLリストと置き換えたIDとを対応付けて記憶する。
 また、SIPクライアント1-2は、INVITEメッセージ受信時に、このINVITEメッセージに含まれる上記IDをそれが設定されていたパラメータと関連付けて記憶する。なお、各種URLリストに対して割り当てるIDは、URLリストの値各々に対して割り当てる。すなわち、IDは、URLリストの種別を示すのではなく、URLリストの内容を一意に示す。
 上記図2に基づいて説明したように、SIPクライアント1-2は、Ringingメッセージ、OKメッセージおよびBYEメッセージを送信する場合、それらのヘッダにViaパラメータ、Record-Routeパラメータ、Recordパラメータを設定するが、これらの値は受信したINVITEメッセージのヘッダに設定されていたURLリストと同じである。そのため、SIPクライアント1-2は、INVITEメッセージで通知されたIDを、上記各送信メッセージのヘッダに設定してノード3-2経由でプロキシ2-2へ送信する。
 ノード3-2は、SIPクライアント1-2からSIPメッセージを受信した場合、まず、そのヘッダに設定されているID(URLリストを一意に示す情報)に対応するURLリストを、記憶しておいたURLリストの中から特定する。次に、受信メッセージのヘッダに設定されているIDを上記特定したURLリストに置き換えた後、プロキシ2-2へ転送する。
 図3の例では、ノード3-2は、INVITEメッセージを受信した際に、そのヘッダ内のViaパラメータに設定されているURLリスト,Record-Routeパラメータに設定されているURLリストをそれぞれ、ID#1,ID#3に置き換えている。また、SIPクライアント1-2は、SIPメッセージ(Ringingメッセージ,OKメッセージ,BYEメッセージ)を送信する場合、それらのヘッダ内のViaパラメータ、Record-Routeパラメータには、本来設定するURLリストに代えて、これらに対応したID#1,ID#3をそれぞれ設定している。そして、ノード3-2は、SIPクライアント1-2からSIPメッセージを受信した場合、そのヘッダ内のViaパラメータおよびRecord-Routeパラメータに設定されているIDを対応するURLリストに置き換えた上でプロキシ2-2へ転送する。
 また、図4は、ノード3-2における圧縮対象パラメータ(Viaパラメータ,Record-Routeパラメータ,Recordパラメータ)の管理方法を示す図である。図示したように、ノード3-2は、プロキシ2-2から受信したSIPメッセージ内の圧縮対象パラメータに設定されていたURLリストとIDを対応付けて管理する。なお、図4の例では、ノード3-2は、SIPクライアント1-2a、SIPクライアント1-2b、SIPクライアント1-2cなど複数のSIPクライアントを管理しているが、SIPクライアントごとにIDを管理する必要はない。すなわち、IDに対応するURLリストをどのクライアントが送信してきたか、どのクライアントに送信すべきか、などを認識しておく必要はない。また、Viaパラメータ、Record-Routeパラメータ、Recordパラメータなどの種別を認識して情報種別毎にIDを管理する必要もない。一方、各SIPクライアントは、セッション情報とIDとを対応付けて管理する。なお、ノード3-1およびこれに接続されたSIPクライアントにおける圧縮対象パラメータおよびそのIDの管理方法も同様である。
 このように、本実施の形態の無線通信システムでは、SIPクライアントとプロキシとの間でSIPメッセージを中継するノードが、SIPクライアントへSIPメッセージを中継する際に、中継するメッセージのヘッダに設定されたパラメータのうち、他のメッセージと関連性を有するパラメータ(Viaパラメータ、Record-Routeパラメータ、Route情報)については、各パラメータの内容(設定された情報)をその情報を一意に示すIDに置き換えることとした。さらに、SIPクライアントから受信したSIPメッセージのヘッダに各パラメータの内容を示すIDが設定されている場合、当該IDを対応する内容に置き換えた上で中継することとした。また、SIPクライアントは、SIPメッセージを送信する場合、そのヘッダに設定するパラメータのうち、他のメッセージと関連性を有するパラメータについては、実際の情報に代えてそれらの内容を一意に示すIDを設定することとした。これにより、SIPメッセージの圧縮効率を向上できる。また、各パラメータの設定値(設定情報)とIDとを置き換える処理を実施するノードは、SIPメッセージのヘッダ内のパラメータのうち、IDに置き換える必要があるパラメータのみを認識できればよく、SIPプロトコル(SIPメッセージ内のパラメータへの設定値)の意味を知らなくてよいというメリットが生じる。
実施の形態2.
 つづいて、実施の形態2について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態1と同様である。図5は、実施の形態2の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図であり、上記図2で示したシーケンスと同様に、図1に示したSIPクライアント1-1からSIPシグナリングを開始する場合の例を示している。なお、図5は、特に、本実施の形態の無線通信システムにおいてSIPメッセージの圧縮・伸張制御を実行する区間に位置しているSIPクライアント1-1、プロキシ2-1およびノード3-1に注目し、これらの間で実行されるシーケンスを示している。以下に、本実施の形態の無線通信システムにおけるシグナリング制御動作を図1および図5に基づいて説明する。なお、実施の形態1と重複する部分については説明を省略する。
 通信開始後、シーケンスが正常に進んでいくと、プロキシ2-1は、ノード3-1経由でSIPクライアント1-1に対して、100 Tryingメッセージ(以下、単に「Tryingメッセージ」と記載する)、Ringingメッセージ、OKメッセージを送信する。このとき、これらのSIPメッセージのヘッダにはViaパラメータやRecord-RouteパラメータとしてURLリストが設定されている。そして、実施の形態1で説明したとおり、各SIPメッセージに含まれるViaパラメータ、Record-Routeパラメータが有する相関関係は、SIPプロトコルを終端するSIPクライアントでは暗黙的に既知とみなすことができる。そのため、ノード3-1は、SIPメッセージをSIPクライアント1-1へ送信する際、この各種URLリストに対してIDを割り当て、ViaパラメータおよびRecord-Routeパラメータに設定するURLリストをこのIDで置き換えるとともに、これらの各種URLリストをIDと対応付けて記憶する。また、SIPクライアント1-1は、上記SIPメッセージを受信した場合、そのヘッダ内のViaパラメータやRecord-Routeパラメータに設定されていたIDを記憶する。なお、各種URLリストに対して割り当てるIDは、実施の形態1と同様に、URLリストの各値(URL)それぞれに対して割り当てる。
 また、SIPクライアント1-1は、OKメッセージを受信し、これの応答としてACKメッセージを送信する場合、そのヘッダ内のViaパラメータおよびRecordパラメータを設定するが、Viaパラメータへの設定値は、その前に受信したOKメッセージのViaパラメータに設定されていた値(URLリスト)と同じである。また、Recordパラメータへの設定値は、受信したOKメッセージのRecord-Routeパラメータに設定されていたURLリストを、その並び順が逆になるように並び替えたものである。したがって、SIPクライアント1-1は、受信したOKメッセージのヘッダ内のViaパラメータに設定されていたIDを、ACKメッセージのヘッダ内のViaパラメータに設定するとともに、受信したOKメッセージのヘッダ内のRecord-Routeパラメータに設定されていたIDと、そのIDが示すURLリストを逆転する(順番が逆になるように並び替える)ことを指示するコード(もしくは文字列:図5では一例として「Reverse」と記載している)をACKメッセージのヘッダ内のRecordパラメータに設定し、ノード3-1経由でプロキシ2-1へ送信する。
 ノード3-1は、SIPクライアント1-1からメッセージを受信した場合、まず、そのヘッダ内に設定されている各IDに対応するURLリストを、記憶しておいたURLリストの中から特定する。次に、受信メッセージのViaパラメータについては、そこに設定されているIDを上記特定したURLリストの中の対応するURLリストに置き換え、一方、Recordパラメータについては、そこに設定されているIDを上記特定したURLリストの中の対応するURLリストを逆転させたもの(順番が逆になるように並び替えたもの)に置き換えた後、プロキシ2-1へ転送する。
 また、通信を終了する際のBYEメッセージを受信した場合、SIPクライアント1-1は、受信したBYEメッセージのViaパラメータに設定されていたIDを、OKメッセージのViaパラメータに設定して送信する。ノード3-1は、受信したOKメッセージのViaパラメータに設定されていたIDを、それに対応する設定値(URLリスト)に置き換えた後、プロキシ2-1へ転送する。
 このように、本実施の形態の無線通信システムでは、SIPクライアントが、あるURLリストを含んだ第1のSIPメッセージを受信し、その応答メッセージとして、受信したURLリストを逆転させて得られたURLリスト(順番が逆になるように並び替えて得られたURLリスト)を含んだ第2のSIPメッセージを送信するシーケンスを実行する場合、第1のSIPメッセージを送信するノードは、URLリストをIDに置き換えた第1のSIPメッセージをSIPクライアントへ送信し、第1のSIPメッセージを受信したSIPクライアントは、受信メッセージに含まれていたIDを第2のSIPメッセージに設定するとともに、当該IDに対応するURLリストを逆転させる旨の指示情報を設定し、この第2のSIPメッセージを受信したノードは、それに含まれているIDに対応したURLリストを指示内容に従って変形し、得られた変形後のURLリストを当該IDに代えて設定した上で対向するプロキシへ転送することとした。これにより、あるSIPメッセージおよびその応答メッセージに設定するURLリストが同一ではなく、順番が逆転したURLリストとなっている場合であっても、冗長パラメータ(URLリスト)を圧縮してSIP圧縮効率を向上させることができる。
 なお、本実施の形態で示した制御動作は、実施の形態1で示した制御動作と並行して実施可能(組み合わせることが可能)である。
実施の形態3.
 つづいて、実施の形態3について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態1と同様である。図6は、実施の形態3の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図であり、上記図2で示したシーケンスと同様に、図1に示したSIPクライアント1-1からSIPシグナリングを開始する場合の例を示している。なお、図6は、特に、本実施の形態の無線通信システムにおいてSIPメッセージの圧縮・伸張制御を実行する区間に位置しているSIPクライアント1-2、プロキシ2-2およびノード3-2に注目し、これらの間で実行されるシーケンスを示している。以下に、本実施の形態の無線通信システムにおけるシグナリング制御動作を図1および図6に基づいて説明する。なお、実施の形態1または2と重複する部分については説明を省略する。
 本実施の形態では、SIPクライアント1-2がRingingメッセージを送信する際に、そのViaパラメータとして、INVITEメッセージで受信したViaパラメータ(URLリスト)をベースに、リストの一番上のURLに対して「received=192.0.2.222」という文字列を追加する場合の制御動作について説明する。
 受信したINVITEメッセージのViaパラメータに設定されたURLリストの一番上のURLに対して「received=192.0.2.222」という文字列を追加して得られた情報をRingingメッセージのViaパラメータに設定して送信する場合、SIPクライアント1-2は、RingingメッセージのViaパラメータに対して、INVITEメッセージで通知されたID(INVITEメッセージのViaパラメータに設定されていたID)と、当該IDに対応するURLリストの最初のURLに文字列を追加することを指示するコード(もしくは文字列:図6では一例として「+」と記載している)と、追加文字列(図6では「recv=192.0.2.222」と記載している)と、を設定してプロキシ2-2宛に送信する。ノード3-2は、上記Ringingメッセージを受信すると、まず、そのViaパラメータに設定されたIDに対応するURLリストを記憶しておいたURLリストの中から特定する。次に、受信したRingingメッセージのViaパラメータに設定されていたIDを上記特定したURLリストに置き換え、さらに、当該受信メッセージに含まれていた指示情報および追加文字列に従い、置き換えたURLリストの先頭に文字列を追加した後、プロキシ2-2へ転送する。
 以上のような手法を用いることで、受信したSIPメッセージに含まれていたURLリストを設定し、このURLリストに対してさらに所定の文字列を追加したSIPメッセージを送信するシーケンスを実行する場合においても、冗長パラメータを削除することができ、SIP圧縮効率を向上させることができる。
 このように、本実施の形態の無線通信システムでは、SIPクライアントが、あるURLリスト含んだ第1のSIPメッセージを受信し、受信したURLリストの最初のURLに文字列を追加して得られたURLリストを含んだ第2のSIPメッセージを送信するシーケンスを実行する場合、第1のSIPメッセージを送信するノードは、URLリストをIDに置き換えた第1のSIPメッセージをSIPクライアントへ送信し、第1のSIPメッセージを受信したSIPクライアントは、受信メッセージに含まれていたIDを第2のSIPメッセージに設定するとともに、当該IDに対応するURLリストの最初のURLに対して文字列を追加する旨の指示情報および追加する文字列を設定し、この第2のSIPメッセージを受信したノードは、それに含まれているIDに対応したURLリストを指示内容に従って変形し、得られた変形後のURLリストを当該IDに代えて設定した上で対向するプロキシへ転送することとした。これにより、SIPクライアントが受信したSIPメッセージに含まれていたURLリストを設定し、このURLリストに対してさらに所定の文字列を追加したSIPメッセージをプロキシへ送信するシーケンスを実行する場合においても、冗長パラメータ(URLリスト)を圧縮してSIP圧縮効率を向上させることができる。
 なお、本実施の形態で示した制御動作は、実施の形態1や実施の形態2で示した制御動作と並行して実施可能(組み合わせることが可能)である。
実施の形態4.
 つづいて、実施の形態4について説明する。なお、本実施の形態の無線通信システムの構成は、上述した実施の形態1と同様である。図7は、実施の形態4の無線通信システムにおけるSIPシグナリングの一例を示すシーケンス図であり、上記図2で示したシーケンスと同様に、図1に示したSIPクライアント1-1からSIPシグナリングを開始する場合の例を示している。なお、図7は、特に、本実施の形態の無線通信システムにおいてSIPメッセージの圧縮・伸張制御を実行する区間に位置しているSIPクライアント1-2、プロキシ2-2およびノード3-2に注目し、これらの間で実行されるシーケンスを示している。本実施の形態では、実施の形態1、2または3と重複する部分については説明を省略する。
 実施の形態1において図2を用いて示したように、SIPクライアント間で送信されるINVITEメッセージのViaパラメータに設定されたURLリストは、発信者となるSIPクライアント(図2の例ではSIPクライアント1-1)のURLを含み、このURLはリストの最後に設定されている。
 そのため、本実施の形態のシグナリング制御動作では、ノード3-2およびSIPクライアント1-2は、以下に示す動作を実行することにより、ノード3-2が必要とするメモリ容量を削減する。
 図7に示したように、本実施の形態のSIPシグナリングでは、ノード3-2は、プロキシ2-2から受信したINVITEメッセージをSIPクライアント1-2へ転送する場合、そのViaパラメータに設定された情報(URLリスト)の中の発信者となるSIPクライアントのURL(以下、「発信者URL」と記載する)を除いたURLリストをIDに置き換える(図7では一例として「#1+SIP/2.0/TCP Client1-1 URL:5060;branch=z9hg4bk74bf9;received=192.0.2.101」に置き換えている)。さらに、Viaパラメータ以外のパラメータ(Record-Routeパラメータ)については、実施の形態1と同様に、設定された情報(URLリスト)のすべてをIDに置き換える。また、IDに置き換えたURLリストは、IDと対応付けて記憶しておく。なお、図7では、Record-Routeパラメータの記載を省略している。
 また、SIPクライアント1-2は、INVITEメッセージ受信時に、それに含まれる上記IDとURL文字列(発信者URL)を記憶する。そして、SIPクライアント1-2は、Ringingメッセージを送信する場合、そのViaパラメータにはINVITEメッセージ受信時に記憶しておいたIDとURL文字列を設定する。なお、図示するのを省略しているが、RingingメッセージのRecord-Routeパラメータには、INVITEメッセージ受信時に記憶しておいたID(INVITEメッセージのRecord-Routeパラメータに設定されていたID)を設定する。このSIPクライアント1-2の動作は、基本的に実施の形態1で示したSIPクライアント1-2の動作と同じである。すなわち、いずれの動作においても、受信したINVITEメッセージのViaパラメータおよびRecord-Routeパラメータに設定されていた情報を記憶しておき、Ringingメッセージを送信する際には、そのViaパラメータおよびRecord-Routeパラメータに対して、INVITEメッセージ受信時に記憶しておいた情報を設定する。
 ノード3-2は、SIPクライアント1-2からRingingメッセージを受信した場合、まず、そのヘッダ内のViaパラメータおよびRecord-Routeパラメータに設定されているIDに対応するURLリストを、記憶しておいたURLリストの中から特定する。次に、受信メッセージのヘッダに設定されているIDを上記特定したURLリストに置き換え、さらにViaパラメータについては、受信したRingingメッセージのViaパラメータに設定されていた発信者URLを設定した後、プロキシ2-2へ転送する。
 このように、本実施の形態の無線通信システムでは、SIPメッセージを圧縮した上で転送するノードは、SIPメッセージを受信した場合、それに含まれているViaパラメータについては発信者URLを除いたURLリストをIDに置き換え、また、その他の情報(Record-Routeパラメータ)については、URLリストすべてをIDに置き換えた上で転送することとした。これにより、ノードで管理するURLリストの中の文字列からSIPクライアントを表現する部位(SIPクライアントのURL)が取り除かれ、SIPメッセージを圧縮するノードは、中継するプロキシのURLのみを管理することとなる。そのため、ノードにおいては、管理するURLリストの文字列が、収容している複数のSIPクライアントで共通になる可能性が高くなる。この結果、ノードが管理するURLリスト情報量が少なくなり、ノードが必要とするメモリ容量を削減できる。
 なお、本実施の形態では、ViaパラメータへIDとともに記載するURL文字列の一例として「SIP/2.0/TCP Client1-1 URL:5060;branch=z9hg4bk74bf9;received=192.0.2.101」を示したが(図7参照)、このように、URL文字列には、実際のURLを示す文字列だけでなく、SIP/2.0/TCPといったプロトコルを表現する文字列、branchなどのオプションが記載可能である。すなわち、Viaパラメータを圧縮する(IDに置き換える)際に対象とするURL文字列は、URLを含んだ一般的な文字列を意味する。
 このような手法を用いることで、URLリストのURL部に各種オプションが付与されていても、冗長パラメータを削除することができ、SIP圧縮効率を向上させることができる。
 また、本実施の形態で示した制御動作は、実施の形態1の変形例であるが、実施の形態2や実施の形態3で示した制御動作と並行して実施可能(組み合わせることが可能)である。
実施の形態5.
 つづいて、実施の形態5について説明する。上述した実施の形態の無線通信システムにおいてSIPメッセージの圧縮を行う各ノードは、図4に示した手法で圧縮処理の対象情報(Viaパラメータ,Record-Routeパラメータ,Recordパラメータ)であるURLリストを管理することとしたが、本実施の形態では、これとは異なる管理方法について説明する。
 図4に示した手法では、各ノードにおいて、たとえばSIPメッセージの圧縮処理を実行するSIP圧縮部がURLリストとIDの一元管理を行っている。しかし、基地局制御装置などではSIPプロトコルは意識しないものの結果的にSIPクライアントと1:1に対応するコネクションを管理する部位が存在している。たとえば、ユーザごとの無線リソースを管理する部位などである。この部位では無線コネクション情報をSIPクライアントに対応させて管理していることになる。このような場合、URLリストを無線コネクション情報と対応付けて管理することができ、IDは一つのSIPクライアントの中でユニークにアサインすればよくなる。たとえば図8に示したように、ノード3-2は、すでに保持している各SIPクライアント(SIPクライアント1-2a,1-2b,1-2c)との間の無線コネクションの管理情報(図示した無線コネクション情報a,無線コネクション情報b,無線コネクション情報c)に対応付けてURLリストのIDを管理することにより、値が同じIDの複数利用が可能になる。図8に示したような圧縮対象パラメータの管理方法を適用した場合、図4に示した手法を適用した場合と比較して、IDの値が大きくなるのを防止できる。
 URLリストとIDの対応表は非常に大きくなるケースがあり、このような場合、図4に示した、コネクション(セッション)を意識せずにURLリストとIDを管理する手法では、SIPクライアントから受信したSIPメッセージ内のIDに対応する情報(URLリスト)を検索して特定する処理に時間を要するという問題が発生する。しかしながら、図8で示した管理方法を用いると、無線コネクションさえ特定できれば、ターゲットとするURLリストを短時間で特定することができるので、上記のような問題が発生するのを防止できる。
 なお、各実施の形態ではSIPのVia、Record-Route、Recordパラメータを例に説明を行ったが、使用方法がこれらと同様のパラメータであれば、同様の手法で圧縮することが可能である。また、各実施の形態では無線通信システムにおける例を示したが、有線通信システムであってもよく、無線通信システムと同様の効果を奏する。
 以上のように、各実施の形態で示した通信システムによれば、SIPプロトコルの意味を知らないノードがSIPメッセージ圧縮を行う場合であっても、冗長なSIPパラメータの削除と復元が可能になり、より大きなSIPメッセージ圧縮効率を達成することができる。たとえば、プロキシ(SIPプロキシ)を20個経由するような構成のネットワークでは、一つのプロキシを表現するURLが20文字であるとすると、Via、Record-RouteのURLリストは各々400バイトとなり、この二つのパラメータが存在するだけで800バイトを要する。一方、SIPメッセージの他のパートはより小さく、SIPメッセージのサイズの観点ではこのURLリストが支配的になってくる。本発明ではこのURLリストをサイズの小さい識別情報(上述したID)に置き換えるため、大きな圧縮効率を実現できる。
 以上のように、本発明にかかる通信システムは、情報伝送量を削減したSIPシグナリングを実現する場合に有用であり、特に、基地局制御装置や基地局などSIPプロトコルを終端しないノードにおいてSIPメッセージの圧縮および伸張を行い、より高い圧縮効率を実現する場合に適している。
 1-1、1-2、1-2a、1-2b、1-2c SIPクライアント(SIP Client)
 2-1、2-2 プロキシ(Proxy)
 3-1、3-2 ノード

Claims (10)

  1.  SIPクライアント、当該SIPクライアントのプロキシ、および当該SIPクライアントと当該プロキシの間に位置し、受信したSIPメッセージを中継するノードを含んだ通信システムであって、
     前記ノードは、
     前記SIPクライアント宛のSIPメッセージを中継する場合、受信したSIPメッセージの特定のパラメータに設定されている管理情報をその内容を一意に示すIDに置き換え、また当該IDと当該管理情報とを関連付けて記憶し、一方、前記SIPクライアントから送信されたSIPメッセージでありかつその特定のパラメータに前記記憶したIDと同じIDが設定されたSIPメッセージを中継する場合、当該IDをこれに関連付けられた管理情報に置き換え、
     前記SIPクライアントは、
     受信したSIPメッセージの特定のパラメータに前記IDが設定されている場合、当該パラメータと当該IDとを関連付けて記憶し、また、当該記憶したパラメータと同じパラメータを含んだSIPメッセージを送信する場合、当該パラメータに対して、これに関連付けられたIDを設定する
     ことを特徴とする通信システム。
  2.  前記管理情報を、前記SIPクライアント宛のSIPメッセージが通過してきた経路上の各プロキシのURL、および当該SIPメッセージの発行元のURL、のリストとすることを特徴とする請求項1に記載の通信システム。
  3.  前記管理情報を、前記SIPクライアント宛のSIPメッセージが通過してきた経路上の各プロキシのURLのリストとすることを特徴とする請求項1に記載の通信システム。
  4.  前記管理情報を、前記SIPクライアント宛のSIPメッセージが通過してきた経路上の各プロキシのURLをそれぞれ含む複数の文字列、および当該SIPメッセージの発行元のURLを含む文字列、のリストとすることを特徴とする請求項1に記載の通信システム。
  5.  前記管理情報を、前記SIPクライアント宛のSIPメッセージが通過してきた経路上の各プロキシのURLをそれぞれ含む複数の文字列のリストとすることを特徴とする請求項1に記載の通信システム。
  6.  前記SIPクライアントは、さらに、
     前記IDと関連付けて記憶したパラメータに対応するURLリストまたは文字列リストの各情報の順番を逆転させて得られたリスト、を設定すべきパラメータを含んだSIPメッセージを送信する場合、送信するSIPメッセージの当該パラメータに対して、前記記憶したパラメータに関連付けられたID、および当該IDを対応するリストに置き換えた後にそのリスト内の各情報の順番を逆転させるように指示する指示情報、を設定し、
     前記ノードは、
     特定のパラメータに前記記憶したIDと同じIDおよび前記指示情報が設定されたSIPメッセージを前記SIPクライアントから受信した場合、当該受信メッセージに設定されているIDを、これに関連付けられたリストの各情報の順番を逆転させて得られたリストに置き換えて転送する
     ことを特徴とする請求項2~5のいずれか一つに記載の通信システム。
  7.  前記SIPクライアントは、
     前記記憶したパラメータと同じパラメータを含んだSIPメッセージを送信する場合、当該パラメータに対して、これに関連付けられたIDを設定し、さらに必要に応じて、当該IDに関連付けて記憶されているリストの所定位置に文字列を追加するように指示する文字列追加指示情報を設定し、
     前記ノードは、
     特定のパラメータに、前記記憶したIDと同じIDおよび前記文字列追加指示情報が設定されたSIPメッセージを前記SIPクライアントから受信した場合には、当該IDをこれに関連付けられたリストに置き換え、さらに、当該指示情報により指示された位置へ指定された文字列を追加し、得られたSIPメッセージを転送する
     ことを特徴とする請求項2~6のいずれか一つに記載の通信システム。
  8.  前記ノードは、前記管理情報をその内容を一意に示すIDと関連付けて記憶するにあたって、さらに、これらの情報を前記SIPクライアントのコネクション情報と対応付けて記憶することを特徴とする請求項1~7のいずれか一つに記載の通信システム。
  9.  請求項1~8のいずれか一つに記載のノードとして動作することを特徴とする通信装置。
  10.  請求項1~8のいずれか一つに記載のSIPクライアントとして動作することを特徴とする通信装置。
PCT/JP2009/067497 2008-10-21 2009-10-07 通信システムおよび通信装置 WO2010047229A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US13/122,737 US20110196976A1 (en) 2008-10-21 2009-10-07 Communication system and communication device
CN200980141680.6A CN102197635A (zh) 2008-10-21 2009-10-07 通信系统以及通信装置
JP2010534770A JPWO2010047229A1 (ja) 2008-10-21 2009-10-07 通信システムおよび通信装置
EP09821927.2A EP2343874A4 (en) 2008-10-21 2009-10-07 COMMUNICATION SYSTEM AND COMMUNICATION DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-270916 2008-10-21
JP2008270916 2008-10-21

Publications (1)

Publication Number Publication Date
WO2010047229A1 true WO2010047229A1 (ja) 2010-04-29

Family

ID=42119271

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/067497 WO2010047229A1 (ja) 2008-10-21 2009-10-07 通信システムおよび通信装置

Country Status (5)

Country Link
US (1) US20110196976A1 (ja)
EP (1) EP2343874A4 (ja)
JP (1) JPWO2010047229A1 (ja)
CN (1) CN102197635A (ja)
WO (1) WO2010047229A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011239270A (ja) * 2010-05-12 2011-11-24 National Institute Of Information & Communication Technology 移動体通信における改良された端末情報管理方式及び通信方式を実現するメッシュ型ネットワーク及び基地局

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6305635B2 (ja) * 2015-04-03 2018-04-04 三菱電機株式会社 メディア通信システム、音声端末および音声符号変換装置
GB2577941B (en) 2018-10-12 2020-10-14 Metaswitch Networks Ltd Proxying session Initiation protocol (SIP) communications

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0444845B2 (ja) 1985-03-01 1992-07-23 Nippon Electric Co
JP2004228829A (ja) * 2003-01-22 2004-08-12 Hitachi Ltd メッセージ変換装置、及びip電話装置
JP2006094488A (ja) * 2004-09-09 2006-04-06 Microsoft Corp 経路情報に関するストレージ要件の軽減
WO2007067509A2 (en) * 2005-12-05 2007-06-14 Lucent Technologies Inc. Method of embedding information in internet transmissions
JP2007282038A (ja) * 2006-04-10 2007-10-25 Mitsubishi Electric Corp 信号伝送装置

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6611875B1 (en) * 1998-12-31 2003-08-26 Pmc-Sierra, Inc. Control system for high speed rule processors
US6510509B1 (en) * 1999-03-29 2003-01-21 Pmc-Sierra Us, Inc. Method and apparatus for high-speed network rule processing
US6678735B1 (en) * 2000-01-26 2004-01-13 Nortel Networks Limited Method and apparatus for a sip client manager
GB2372180A (en) * 2001-02-07 2002-08-14 Motorola Inc Compression of SIP/SDP headers by omitting standard fields from transmission and insertion of omitted fields from cache at receiver
US7266593B2 (en) * 2001-02-23 2007-09-04 Nokia Networks Oy IP based service architecture
FI118244B (fi) * 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US20030120813A1 (en) * 2001-12-21 2003-06-26 Ishita Majumdar Apparatus and method for optimizing message sizes of textual protocols used in multimedia communications
US7020440B2 (en) * 2002-12-13 2006-03-28 Ntt Docomo, Inc. Method and apparatus for an SIP based paging scheme
US7289464B2 (en) * 2003-02-18 2007-10-30 Qualcomm Incorporated Compression using program tokens
US8036211B1 (en) * 2004-03-09 2011-10-11 Genband Us Llc Legacy user proxy call session control function
US7599374B2 (en) * 2004-03-10 2009-10-06 Nokia Corporation System and method for establishing an Internet Protocol connection with a terminating network node
US7283803B2 (en) * 2004-04-16 2007-10-16 Broadcom Corporation Location-aware application based quality of service (QOS) via a broadband access gateway
US8238329B2 (en) * 2005-12-13 2012-08-07 Transnexus, Inc. Method and system for securely authorizing VoIP interconnections between anonymous peers of VoIP networks
CN100456834C (zh) * 2005-10-17 2009-01-28 华为技术有限公司 H.264多媒体通信的服务质量监测方法
US7903635B2 (en) * 2006-03-02 2011-03-08 Tango Networks, Inc. System and method for enabling DTMF detection in a VoIP network
US8140707B2 (en) * 2006-04-24 2012-03-20 Kt Corporation Inter working system
US8144587B2 (en) * 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
EP2165505B1 (en) * 2007-07-10 2016-06-01 Telefonaktiebolaget LM Ericsson (publ) A method of discovering operator-provided network-services using ims.
US20090150562A1 (en) * 2007-12-07 2009-06-11 Research In Motion Limited Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US20090147684A1 (en) * 2007-12-10 2009-06-11 Reza Majidi-Ahy Dynamic, integrated, multi-service network cross-layer optimization
JP5001436B2 (ja) * 2008-01-10 2012-08-15 テレフオンアクチーボラゲット エル エム エリクソン(パブル) 通信ネットワークにおけるメッセージの処理
KR101455125B1 (ko) * 2008-08-08 2014-10-27 알까뗄 루슨트 개선된 이용자 서비스들을 위한 sip 포킹에 대한 강화
EP2175607A1 (en) * 2008-10-08 2010-04-14 NEC Corporation Method for establishing a thin client session

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0444845B2 (ja) 1985-03-01 1992-07-23 Nippon Electric Co
JP2004228829A (ja) * 2003-01-22 2004-08-12 Hitachi Ltd メッセージ変換装置、及びip電話装置
JP2006094488A (ja) * 2004-09-09 2006-04-06 Microsoft Corp 経路情報に関するストレージ要件の軽減
WO2007067509A2 (en) * 2005-12-05 2007-06-14 Lucent Technologies Inc. Method of embedding information in internet transmissions
JP2007282038A (ja) * 2006-04-10 2007-10-25 Mitsubishi Electric Corp 信号伝送装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2343874A4

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011239270A (ja) * 2010-05-12 2011-11-24 National Institute Of Information & Communication Technology 移動体通信における改良された端末情報管理方式及び通信方式を実現するメッシュ型ネットワーク及び基地局

Also Published As

Publication number Publication date
EP2343874A4 (en) 2014-03-05
EP2343874A1 (en) 2011-07-13
CN102197635A (zh) 2011-09-21
JPWO2010047229A1 (ja) 2012-03-22
US20110196976A1 (en) 2011-08-11

Similar Documents

Publication Publication Date Title
US7817630B2 (en) Method, communications node, and memory for dynamic dictionary updating and optimization for compression and decompression of messages
EP1856896B1 (en) Transferring state information in a network
US7738448B2 (en) Method for generating and sending signaling messages
KR101030469B1 (ko) 시그널링 압축/압축 해제
US20040240399A1 (en) Transcoding arrangement in a session initiation
US20090013078A1 (en) Optimized Signaling Protocol, Including Session Initiation Protocol (SIP), in a Communications Environment
US20080037509A1 (en) Method and communications node for creation and transmission of user specific dictionary for compression and decompression of messages
CN107113223B (zh) 用于消息会话中继协议会话的消息块大小的协商
CN1870639B (zh) 初始会话协议消息编码能力的协商方法及装置
US20040255039A1 (en) Method, system and network element device for controlling sessions between terminals
US20060133372A1 (en) Apparatus and method for multiplexing packet in mobile communication network
WO2010047229A1 (ja) 通信システムおよび通信装置
US20190394144A1 (en) Method of splitting application messages in an ip network
CN101197825A (zh) 一种传输压缩消息的方法、系统及设备
TWI656765B (zh) 傳輸系統及傳輸方法
JP2007282038A (ja) 信号伝送装置
Ahsan et al. Multipath RTP (MPRTP) draft-ietf-avtcore-mprtp-03
JP2010245835A (ja) Sipメッセージ圧縮解凍装置および無線基地局
KR101006141B1 (ko) Sip 메시지 전송 방법
Eggert Multipath RTP (MPRTP) draft-ietf-avtcore-mprtp-00
Eggert et al. AVT Core Working Group V. Singh Internet-Draft T. Karkkainen Intended status: Experimental J. Ott Expires: January 7, 2016 S. Ahsan Aalto University
Eggert Multipath RTP (MPRTP) draft-singh-avtcore-mprtp-10

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980141680.6

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09821927

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010534770

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 13122737

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2009821927

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE