KR100437180B1 - Apparatus and Method for parsing the SIP message and producing method there of - Google Patents

Abstract

The purpose is to enable efficient use of memory resources when parsing SIP (Session Initiation Protocol) messages, and to improve encoding performance when generating SIP messages.

In order to achieve the above object, the present invention separates and stores a header field from a received SIP message, stores pointer information indicating a stored location in a separate storage area, and then parses the request from the outside using this pointer information. It parses the header field, inserting a null string at the parsing location so that the parsed SIP components can share the same address storage.

Description

Apparatus and Method for parsing the SIP message and producing method there of}

The present invention relates to an apparatus and method for parsing an SIP message and a method for generating an SIP message for determining whether to encode an SIP message according to whether a parsed result is modified.

Recently, due to the spread of home PC and high-speed communication network, interest in the telephone using the Internet is increasing, and protocols for enabling such telephones include H.323 and SIP.

In particular, Session Initiation Protocol (SIP) is a text-based protocol such as Hypertext Transfer Protocol (HTTP), and is currently used for call set up in various fields including Internet telephony. Voice call and E-mail service are available anytime, anywhere using SIP ID (Identifier).

A SIP network that performs these SIP functions will be described with reference to FIG. 1.

1 is a diagram schematically illustrating a general SIP network.

Here, reference numeral 10 denotes a SIP proxy server, which serves as a router in the IP network, and delivers SIP messages to SIP terminals at the receiving side and the transmitting side when making a telephone call. , 11 is a directory server that stores address information of the SIP user, and 12 is a registrar, which registers the location of the SIP user on the SIP network, that is, the location of the SIP telephone to which the SIP user will receive calls. And reference numerals 13, 14 and 15 denote SIP telephones.

In the SIP network configured as described above, when a user using a SIP telephone service through a SIP telephone of code 14 moves to a SIP telephone of code 15, the user first announces his or her location via a SIP terminal of code 15 Is transmitted to the registrar 13, and the registrar 13 registers the user's location in the directory server 11 using the transmitted SIP message.

Then, when the other party calls the user through the SIP telephone of 13, the SIP Proxy Server delivers the SIP message of the other party to the new user's position, that is, the SIP telephone of 15, and the user is moved. Will be able to receive SIP messages from you.

SIP messages used in SIP follow the message structure proposed in Request for Comments (RFC) 822 in text form, and are generally divided into start line, header, and body fields. For example, the structure is as follows.

1. Start line field.

INVITE sip: watson@boston.bell-tel.com SIP / 2.0

2. Header field

Via: SIP / 2.0 / UDP sip.ieee.org; branch = 1

From: A.Bell <sip: a.g.bell@bell-tel.com>

To: T.Watson <sip: waston@bell-tel.com>

CSeq: 1 INVITE

Subject: Mr.Waston, come here.

Content-Type: application / sdp

Content-Length: 50

3. Body field.

v = 0

s = Let's talk

c = IN IP4north.east.isi.edu

On the other hand, the general SIP message parsing that parses these SIP messages receives the SIP message in the form of text and parses the whole at the same time, and allocates and stores the memory having different addresses for each SIP component which is the result of parsing.

For example, parsing the "Via" header described above results in a SIP message with protocol name "SIP", protocol version "2.0", transport "UDP", and transport host "sip.ieee.org". Are extracted from "SIP", "2.0", "UDP", and "sip.ieee.org", and allocates the memory having different addresses, and stores them as above. UDP "and the like are referred to herein as" SIP components ".

However, such a message parsing method allocates and releases memory for each " SIP component " as described above, thereby degrading memory processing performance, and in particular, SIP configuration, which is a result of parsing and parsing header fields that need not be parsed. Allocating memory per element wastes memory resources unnecessarily.

Also, when a SIP proxy server that processes a large amount of SIP messages modifies the header field and encodes it into a SIP message, the modified header is generally parsed by modifying the modification after parsing the header field. Is encoded and included in the SIP message. At this time, since not only the modified header field but also the unmodified header field are encoded, this causes a problem of degrading the encoding processing performance of the message.

Accordingly, an object of the present invention is to solve the above problems, and to provide an SIP parsing apparatus, a method, and a method for generating the same, capable of efficiently operating memory resources and improving message encoding processing performance. have.

In order to achieve the above object, the apparatus and method for parsing SIP message of the present invention stores a header field separated from a SIP message, stores the location of the stored header field in a separate storage area, and then uses the location information. Parse specific header fields according to a thread's parsing request, and insert a null string at the parsing location so that the parsed SIP components can share the storage of the same address. .

In another embodiment of the present invention, a method for generating an SIP message may include storing a header field separated from a SIP message, designating a start position and a size of the stored header field as a pointer, storing the header field in a separate storage area, and then using the same as an external thread. When the encoding request is made, the storage location of the header field to be encoded is determined, and it is determined whether the header field to be encoded is a modified head field. As a result of the determination, the modified header field is encoded into the SIP message and not modified. In the case of a header field, the stored header field is copied to a SIP message.

1 is a diagram illustrating a general SIP network,

2 is a diagram illustrating an apparatus for parsing a SIP message according to the present invention;

3 and 4 illustrate pointer information applied to the present invention.

5 is a diagram illustrating another SIP message parsing method according to the present invention;

6 and 7 illustrate another method for generating a SIP message according to the present invention.

Hereinafter, the present invention will be described with reference to the accompanying drawings.

First, the SIP message parsing apparatus of the present invention uses a preprocessor 20 that separates a header field from a SIP message and designates a start position of the separated header field as a pointer, and the pointer information. A parser 21 for parsing a specific header field according to a parsing request of an external thread, a database for storing the result parsed by the parser 21 and the header field and pointer information separated by the preprocessor 20 And an API processor 23 for interfacing the database 22 with an external thread that makes the parsing request.

The database 23 indicates a message storage unit 24 for storing start line / header / body fields separated from the preprocessor 20, and indicates the position of each field stored in the message storage unit 24. An index array storage unit 25 that stores pointer information and a structure storage unit 26 that stores a result parsed by the parser unit 21 in a data structure.

In this SIP message parsing apparatus, the preprocessor 20 first divides the SIP message into a start line / header / body field and stores it in the message storage unit 24 of the database 22.

Then, the preprocessor 20 stores the designated pointer information in the index array storage 25 by designating the location and size of each field stored in the message storage 24 as a pointer.

For example, as shown in FIG. 3, the location where the start line field information of "INVITE sip: jeongwoo@lge.com SIP / 2.0" is stored is a start line pointer and a header field such as "Via". The location where is stored is a header pointer, and the location where body field information, such as v = 0, is stored using a body pointer so that each field is stored.

In particular, because the same header field may exist in the SIP message, each header field is stored using a separate header pointer. In this case, two "Via" fields, which are identical header fields, are stored. The location is divided into a linked list. The first node of the header pointer indicates the location where "Via: SIP / 2.0 / UDP lg-proxy.com" is stored, and the second node is "Via: SIP." /2.0/UDP ns.lge.com ".

On the other hand, while the preprocessor 20 indicates the location of each field as a pointer and stores the information in the index array storage unit 25 in the database 22, a specific header field is parsed from an external thread and the result is obtained. When the API call data for requesting transmission is input, the API processing unit 23 checks whether a specific header field parsed according to the API call data has already been parsed.

When the parsing result is not parsed, the location of the specific header field is determined by using the pointer information of the index array storage unit 25, and then the storage area corresponding to the size of the specific header field is stored. In step 24, the specific header field is copied to the allocated copied momery.

Then, when the API processing unit 23 transmits information to the parser unit 21 that the specific header field is copied to the message storage unit 24, the parser unit 21 stores a copy of the corresponding header field. The parsing operation is performed in a copied memory.

The parsing operation is performed by separating the data included in the specific header field, that is, SIP components by using a token, wherein a null string is inserted after the position of the token to insert the same address. Allows multiple parsed SIP components to share their storage area.

For example, as illustrated in FIG. 4, when the data included in the corresponding header field is "Via: SIP / 2.0 / UDP 1g-proxy.lge.com" indicated by the first node, the data is copied into a copy memory (copied). After parsing in memory, the SIP components are separated into tokens, "Via＼SIP＼2.0＼UDP＼lg-proxy.lg.com", which is followed by a null string () after each token. By inserting 0), SIP components such as "Via", "SIP" ... can share the storage address of the same address, so that processing performance deterioration caused by frequent storage allocation / release operations cannot be prevented. Will be.

On the other hand, parsing "Via: SIP / 2.0 / UDP lg-proxy.lge.com" pointed to by the first node's pointer, then "Via: SIP / 2.0 / UDP / ns.lge." Pointed to by the second node's pointer. com is parsed in the same manner as described above, where the two nodes are linked in a linked list.

When the above parsing operation is completed, the parser 21 stores the SIP components as a result of parsing in the data structure storage 26, which is a separate storage area, and then stores the SIP components in the form of a structure. 23) returns to the external, that is, application thread of the operating system.

Next, another method of parsing SIP message according to the present invention will be described with reference to FIG. 5.

As shown in FIG. 5, the SIP message parsing method of the present invention includes a 51 st step of receiving a SIP message (S51), and a 52 th step of separating the received SIP message into a start line / header / body field ( S52), a 53rd step (S53) of storing each separated field and the location where the field is stored; a 54th step (S54) of requesting a parsing result of a specific header field from an external thread, and a specific header requested to be parsed. A 55th step (S55) of identifying the location where the field is stored in the original memory; a 56th step (S56) of determining whether the requested specific header field has already been parsed; and copying the specific header field to the copy memory. Parsing step 57 (S57), parsing the header field to extract the extracted SIP components in the corresponding storage area of the structure memory (S58), and stored SIP components in the form of a structure It comprises a first step 59 (S59) to return to the thread.

In the SIP message parsing method, the SIP message is first received (S51) and the received SIP message is separated into a start line / header / body field (S52).

Then, each of the separated fields is stored, and pointer information indicating the location of each stored field is stored in a separate storage area (S53).

In this state, for example, when data for requesting a parsing result of a specific header field is input from an application thread of an operating system (S54), the location of the specific header field is determined using the pointer information (S55). It is determined whether parsing of a specific header field has already been made, and this determination is determined using flag information included in the specific header field.

As a result of the determination, if parsing of a specific header field has already been made, the parsed result is returned to an external thread in the form of a structure (S59). On the other hand, if parsing is not performed, a specific header field is returned from the original memory. Extract it, copy it to copy memory, and parse it (S57).

That is, the specific header field is extracted from the original memory and copied to the copy memory, and then the copied specific header field is parsed. At this time, the SIP components, which are the result of parsing the specific header field, are stored in the same address. The null string should be inserted after the token separating each SIP component so that the realm can be shared.

After parsing the specific header field, the parsed SIP components are stored in the structure memory, and the stored SIP components are returned to the external thread in the form of a data structure.

For example, the specific header is "Via: SIP / 2.0 / UDP lg-proxy.lge.com", and the parsing result is "Via＼0SIP＼02.0＼0UDP＼0lg-proxy.lg.com＼0". If you define the structure using C language as follows:

typedef strut_ Via {

strut_Via * next;

Bool bls Modified;

Bool blntoSignature;

char * szOrgMsg; / * pointer to the original header message * /

int nOrgLen; / * length of original header message * /

char * szProtocolName;

char * szProtocolVersion;

char * szTransport;

char * szHost; ........ char * szComment;}

SIPPAR_Via_t ;.

At this time, "szProtocolName" is "SIP \ 0", "szProtocolVersion" is "2.0 \ 0", "* szTransport" is "UDP \ 0", and "szHost" is "lg-proxy.lg.com" Each character string value corresponding to 0 "is recorded and returned to the external or operating system application thread.

Next, another exemplary SIP message encoding method using the parsing method will be described with reference to FIGS. 6 and 7.

FIG. 6 is a diagram illustrating a step of encoding a flag in the specific header indicating that the header is a modified header by modifying a specific header, and FIG. 7 illustrates a SIP header of a specific header field using the flag information. A diagram illustrating the steps of encoding into a message.

First, a modification of a specific header field will be described with reference to FIG. 6.

As shown in FIG. 6, first, a SIP message is received (S60), and the received SIP message is divided into a start line / header / body field (S61), and each of the separated fields is stored and indicates a stored location. The pointer information and its size are stored (S62).

In this state, when a request for modifying a specific header is input from an external thread (S63), the location of the specific header field is determined using the pointer information (S64).

Then, it is determined whether the specific header field has already been parsed (S65), and when the parsing has already been performed, the parsed result is modified in the stored structure memory (S67). SIP components share the memory of the same address and release the storage state to allocate storage space separately for each component, and then make modifications in the allocated storage space.

For example, typedef strut_ Via {

strut_Via * next;

Bool bls Modified;

Bool blntoSignature;

char * szOrgMsg; / * pointer to the original header message * /

int nOrgLen; / * length of original header message * /

char * szProtocolName;

char * szProtocolVersion;

char * szTransport;

char * szHost; ........ "SIP＼0" for szProtocolName "and" 2.0＼ "for" szProtocolVersion "in the structure defined by char * szComment;}" 0 "," * szTransport "is" UDP \ 0 ", and" szHost "contains the parsing result of" lg-proxy.lg.com \ 0 "as the character string value, and" szP \ 0 "of szTransport. In case that "SCTP_0" is to be modified, since the "SCTP" having a 4-bit size cannot be recorded in the position of "UDP" which is a 3-bit size, the SIP components, i.e., SIP, 2.0 , UDP, etc., cancel the storage state sharing the memory of the same address, and allocate the storage area separately for each component so that modification can be made in the allocated storage area.

On the other hand, as described above, if parsing of a specific header has not already been performed, the specific header stored in the original memory is copied to a copy-memory memory and parsed, and then the specific header is modified using the parsing result.

When the above-described modification step S67 ends, a flag indicating that the header is a modified header is encoded into the specific header field. For example, if the header indicates that the header is a modified header, the field "1" is displayed. If it indicates that it is an unmodified header, it encodes "0" in the corresponding field.

When this flag is encoded, the result is sent to the external thread as a return value.

Next, the step of encoding the SIP message in the modified state is described with reference to FIG.

As shown in FIG. 7, when a request for encoding a specific header field is first input to a SIP message (S70), the location where the original of the specific header field is stored is determined using the pointer information (S71). Whether the header field is a modified header field is determined using the flag information (S72).

As a result of the determination, when the specific header field is the modified field, the header field is extracted from the structure memory stored in the data structure of the specific header field and encoded in the SIP message (S73). If is an unmodified field, the original message of the specific header field is copied directly to the SIP message without encoding (S74) so that only the unmodified specific header field is performed for the SIP message encoding operation.

As described in detail above, an SIP message parsing apparatus, a parsing method, and a generating method thereof according to the present invention can efficiently operate limited memory resources when parsing a SIP message, and encode an encoding process when encoding a SIP message of a specific header. Processing) can dramatically improve performance.

Although the invention has been described in detail only with respect to the specific examples described, it will be apparent to those skilled in the art that various modifications and variations are possible within the spirit of the invention, and such modifications and variations belong to the appended claims.

Claims (7)

A preprocessor that separates the header field from the SIP message and specifies the starting position and size of the separated header field as a pointer; A parser unit for parsing a specific header field according to a parsing request of an external thread using the pointer information; A database for storing the result parsed by the parser and the header field and pointer information separated by the preprocessor; SPI message parsing device comprising an external thread that makes the parsing request and an API processing unit for interfacing the database. The method of claim 1, wherein the database; A message storage unit for storing the header field separated from the preprocessor; An index array storage unit for storing pointer information designated by the preprocessor; SPI message parsing device comprising a structure storage unit for storing the result parsed by the parser. Storing the header field separated from the SIP message; Designating and storing a starting position and a size of the stored header field as a pointer; And parsing a specific header field only when the external thread parses the request using the stored pointer information. 4. The method of claim 3, wherein said parsing step; Receiving a parsing request of a header field from an external thread; Determining a location in which a header field to be parsed is stored using the point information according to the transmitted parsing request; Copying the header field of the storage location to a separate storage area; Parsing the copied header field. The method of claim 3 or 4, wherein the parsing step; And parsing by inserting a null string at a parsing position of the header field. Storing the header field separated from the SIP message; Designating and storing a starting position and a size of the stored header field as a pointer; Determining a storage location of a header field to be encoded in an encoding request of an external thread using the pointer information; Determining whether the header field to be encoded, whose storage location is identified through the information, is a modified head field; And encoding the modified header field in the SIP message when the head field is modified as a result of the determination. The method of claim 6, wherein the determination result; If the header field to be encoded is an unmodified header field, copying the stored header field to a SIP message.