KR100800793B1 - System message transmission method in session initiation protocol - Google Patents

Abstract

The present invention relates generally to session initiation protocol (SIP) technology, in particular Instant Messaging (IM), Push-to-Talk Over Cellular (PoC), Multimedia Messaging (MMS) functionality and service providers performed as hosts. A technique for transmitting system messages to various SIP-based service subscribers, such as any other SIP-based service. System messages are special types of messages sent by the system for various other purposes (e.g., charging announcements, service notifications, alerts, commands, etc.). These system messages usually contain a list of available options and require a response from the user. The present invention is to perform a system message by SIP by inserting a new content and a feature tag in the existing SIP structure in the form of a MIME body to transmit specific service information and receive a user response. We propose a system and method.

Session Initiation Protocol (SIP), system messages

Description

How to send system messages in session initiation protocol {SYSTEM MESSAGE TRANSMISSION METHOD IN SESSION INITIATION PROTOCOL}

1 is a diagram illustrating a process of a client receiving a system message request from a server;

2 is a diagram illustrating a process of a client transmitting a system message response to a server;

3 is a diagram illustrating a system message transmission process according to a general SIP MESSAGE METHOD;

4 is a diagram illustrating a system message transmission process according to an MSRP SEND method;

5 is a diagram illustrating a system message transmission process according to a SIP INFO method.

The present invention relates to Session Initiation Protocol (SIP) technology, and in particular, Instant Messaging (IM), Push-to-Talk Over Cellular (PoC), Multimedia Messaging Service (MMS) and Service Provider (Service Provider). The present invention relates to a method for transmitting a system message to various SIP-based service subscribers such as any other SIP-based service performed as a host.

A system message is a special type of message sent by the system for a variety of different purposes, for example, charging announcements, service notifications, alerts, commands, and the like. These system messages usually include a list of available options and may request a response from the user.

SIP is a protocol for controlling a multimedia session on the Internet, and includes a MESSAGE method, a Message Session Relay Protocol (MSRP) method, and a SIP INFO method.

The MESSAGE method (RFC 3428, reference literature, "Session Initiation Protocol (SIP) Extension for Instant Messaging", B. Campbell, Ed., Et. Al., RFC 3428, December 2002) allows for the delivery of instant messages (IM). SIP (RFC 3261, reference, "SIP: Session Initiation Protocol", J. Rosenberg, et. Al., RFC 3261, June 2002). Because message requests are an extension to SIP, they inherit the routing and security features of all requests of the SIP protocol. Message requests send content in the Multi-purpose Internet Mail Extension (MIME) body format. The message requests themselves do not create a SIP dialog, and when used normally, each instant message exists independently, similar to a pager message. Message requests may be sent in a dialog generated by any other SIP request.

MRSP (see "The Message Session Relay Protocol", B. Campbell, Ed., Et. Al., Draft-ietf-simple-message-sessions) is a protocol for sending a series of related instant messages within a session. to be. The MSRP is a text-based connection-oriented protocol for exchanging arbitrary or binary MIME content, in particular instant messages.

The SIP INFO method (RFC 2976, reference, "The SIP INFO Method", S. Donovan, RFC 2976, October 2000) enables the transfer of session related control information generated during one session.

However, each of the above methods alone cannot accommodate the requirements of system messages. That is, it is impossible to distinguish between normal messages and system messages, does not identify a response received from the client with respect to the system message, fails to wait for a specified period even if the server is expecting a response from the client, and the server does not There is a problem in that it does not provide friendly service level access control.

Accordingly, the present invention provides a method for transmitting a system message that can be distinguished from normal messages and system messages.

The present invention provides a system message transmission method that can identify the type of response that the server wishes to receive from the client.

The present invention provides a system message transmission method that can wait for a specified period when the server is expecting a response from the client.

The present invention provides a system message transmission method that can provide necessary user-friendly service level access control from a server.

The present invention provides a system message transmission method that allows a server to send system messages to clients, receive a response from the client, and determine subsequent actions based on the service provider's policy.

The present invention provides a system message transmission method applicable to the MESSAGE method, MSRP SEND method, SIP INFO method.

In order to achieve the above objects, the present invention provides a method for transmitting a system message in a session initiation protocol, wherein the server adds a feature tag indicating a system message to a message header of a SIP message, and includes system message related content in a message body. A system message request corresponding to the current situation by describing an MIME content type indicating that a message is present, and including an eXtensible Markup Language (XML) document including a content related to a system message request in the message body. And the client receives the system message request, adds the feature tag to the message header of the SIP message, and describes the MIME content type in response to the received system message request. The system in the message body Configure the message system message response (System Message Response) including the system message response XML document containing content related to the response to the request to include the step of transmitting to the server.

The system message request and system message response are then sent by MESSAGE, MSRP SEND, INFO or other suitable SIP method.

The feature tag is included in an Accept-Contact field of the SIP message header, and the MIME content type is included in a Content-Type field.

The feature tag is a + g.application.smsg tag, and the MIME content type is vnd.example.system-message + xml.

The system message request XML document starts with a <system-message> root element, and an smsg-type element indicating whether the system message is a request or a response, an arbitrary system message request, and a system message response thereto. <Smsg> element containing an individual identification number for combining the <smsg-text> element containing any information to be sent to the client, and <smsg-text> element including any type of response to the client in response to the system message request. The smsg-response-type> element, the inclusion or non-determination according to the type of response included in the <smsg-response-type> element, the <answer-options> element containing the specific content and the identifier of the response, and A <verification> element containing code for determining whether a user of the system message request is confirmed, and the system A <time-out> element indicating the wait time for receiving a system message response to the message request, and a <restrict- requesting the client to block other connections associated with the service until the user responds with the system message request. Contains an access> element.

In addition, the <smsg-response-type> element includes only one of two answers, 'no-answer' which does not require a response from the user, and the user's response is different from accept or reject. The <answer-options> element including at least one response type including a "only-one-answer" for selecting a message and a "multiple-answer" for requesting a plurality of user responses. Is not included in the system message request document when the value of the <smsg-response-type> element is non-responsive, and includes an identifier corresponding to each response when it is one of the one-time response or multiple responses. a child element including an option-id> element and a <answer-option-text> element containing text indicating the specific meaning of each response, wherein the <verification> element is a time element. As a child element, a <verification-text> element containing an alphanumeric code to be entered by the user in response to a stem message request, and a <verification-uri> element containing a URI of the alphanumeric code is provided. .

The <time-out> element, the <restrict-access> element, and the <verification> element are optionally included in the system message request XML document.

And the system message response XML document includes the <smsg-type> element, the <smsg> element, a <answer> element including a user's response to the system message request, and the < and the <verification> element including a numeric string input from a user corresponding to the alphanumeric string included in the verification> element.

Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. It should be appreciated, however, that the disclosed embodiments may be embodied in many different forms only as illustrative of the invention. The following description and drawings are not to be construed as limiting the invention, but are merely described to provide a thorough understanding of the invention, as a basis for the claims and methods of making or using the invention. It is to be understood that the invention is described as a basis for teaching those skilled in the art. In some cases, however, the description is omitted for known or customary parts in order to avoid unnecessarily describing the invention in order to obscure the subject matter.

A system message is a special type of message sent by the system for a variety of other purposes, for example, charging announcements, service notifications, alerts, commands, and the like. These system messages usually include a list of available options and may request a response from the user. The timing for sending such messages is in accordance with the policy of the Service Provider. The response of the terminal user may be used to influence negotiations related to the corresponding service.

The present invention inserts new content in the MIME format of the SIP message body in order to transmit information and receive a user response using the system message, and inserts a new feature tag into an existing SIP message header. The present invention provides a method for transmitting a system message that satisfies various system message requirements by transmitting as a. The above method of including new content in the body of the MIME type of the SIP message and delivering the same may be applied to, for example, the MESSAGE method, the MSRP SEND method, and the SIP INFO method. Hereinafter, the present invention will be described in detail.

The system message feature is that it must be supported by both client and server. Also, system messages must be distinguished from other normal messages because they must be uniquely acknowledged by the client and server. Accordingly, the present invention inserts a new feature tag into the message header of the SIP message so that the server recognizes whether or not the client supports the system message, and allows the transmission and reception system to independently identify one system message. The new feature tag may be referred to as + g.application.smsg, for example, and the new feature tag may be applied to any service, for example, an IM service, a PoC service, or an MMS service. feature tag, ie + g.application.smsg. The tag's ASN.1 identifier is New assignment by IANA, and the feature tag indicates that the client supports system messages. And suitable values to use as feature tags are Booleans. Feature tags are primarily used in the following applications, protocols, services or processing mechanisms and are useful in communication applications to describe the capabilities of a device such as a telephone or PDA. For example, setting a route (routing) of the system message to a mobile terminal capable of supporting system messages. The new feature tag must be registered by the client during the SIP register phase. The SIP header field is used to indicate support for system messages. For example, the "Accept-Contact" header may be required and explicit parameters according to the rules and procedures defined in RFC 3841 "Caller Preferences for the Session Initiation Protocol." Can be used to deliver the new feature tag. The new feature tag can be used in several SIP methods for system messages. The SIP MESSAGE method can be applied to the present invention to send and receive system messages regardless of whether the system message is sent in one session, and the SIP INFO method and the MSRP SEND method are applied to the present invention to send system messages during the session. It may be.

And according to the present invention, a new MIME type must be defined in the system message. The new MIME type is uniquely identified as, for example, the vnd.example.system-message + xml MIME content type. The MIME content type described above is used to confirm that the SIP message body contains one system message conforming to a particular structure (XML schema). The MIME content type is applicable to any service, for example, IM service, PoC service, MMS service. The new MIME content type must also be represented in various SIP methods for system messages. That is, the SIP MESSAGE method can be used to send and receive system messages regardless of whether or not the system message is sent within a session, and the SIP INFO method and the MSRP SEND method can be used to send system messages during the session. It may be. The new MIME type may be included in a header field of a SIP message, for example, a content type header.

Meanwhile, system messages conforming to a new MIME content type are transmitted in a message body of various SIP methods during transmission and reception. Accordingly, the message body should be described according to a new structure defined by the new MIME content type. System messages are sent to the client only when needed, usually in the case of first use, for example. Thus, the server maintains a state in which the service provider can recognize to whom and to whom the system message has already been sent. Therefore, the structure defined by the new MIME content type in the message body is defined such that system messages that can be used by the server to transmit system messages and messages used by the client to respond back to the server have the same structure. That is, it is possible to have a single structure that can perform both system message requests and system message responses.

First, the structure of the system message request document is as follows. A system message request document is an XML document that must be well-formed and valid. This system message document is written based on XML 1.0 and uses UTF-8 encoding. The present invention defines and uses an XML namespace to uniquely identify a System Message Request document or a fragment of this document. The namespace URI for elements defined in the description of the present invention is one URN using a namespace identifier called 'example', as follows:

urn: example: params: xml: ns: application: system-message

The system message request document starts with the <system-message> root element, and includes the <smsg-type> element, the <smsg> element, the <smsg-text> element, the <smsg-response-type> element, and the <answer-options> element. , <answer-option-id> element, <answer-option-text> element, <verification> element, <verification-text> element, <verification-uri> element, <time-out> element, <restrict-access> It may contain an element.

Table 1 shows the definition of each element.

Element name What is described in the element smsg-type Indicates whether it is a "request" or "response" smsg Unique number to associate the request with a response smsg-text System message text smsg-response-type Type of response requested "no-answer" or "only-one-answer" or "multiple-answer" answer-options List of response options answer-option-id Unique number to identify the response option answer-option-text Free text response options verification Confirm that the user has read the system message verification-text Validation code that the user must reenter in the response verification-uri URI of the location where the user must enter the code in the response time-out Estimated duration of user response restrict-access Require client to block further access to services until user responds to system message

Referring to Table 1, each element is described in detail as follows.

The <smsg-type> element indicates that a system message described later is in the form of a "Request", and means that it is directed from the server to the client.

The <smsg> element is an element containing a unique identification number assigned to associate a single system message request with a response thereto. This identification number allows the system to send two or more system messages at the same time, reducing the overhead of message and signal exchange. This identification number also helps the server associate the system message response with the system message request, which will be delivered long after the client.

The <smsg-text> element is an element that provides arbitrary information to be delivered to the user.

The <smsg-response-type> element is an indicator indicating what kind of response is requested from the user in response to a system message request. The <smsg-response-type> element is a 'no-answer' and a 'one-time response'. one-answer 'or' multiple-answer '. No-answer is a system message sent by the server is sent only to inform the user, and is used when no response is expected from the user. Only-one-answer is used when system messages sent by the server need only receive one-time responses in the form of Accept / Refuse or Yes / No from the user. Multiple-answers are used when system messages sent by the server need to receive multiple responses from the user. The server determines the value of the <smsg-response-type> element based on the type of response to request from the user. The client must respond according to the type of response requested by the server.

The <answer-options> element is a element describing a set of possible response options that the user can select as a response, and may include a plurality, and if present, this means that the server is expecting a response from the user. do. Therefore, the <answer-options> element does not exist when the value of the <smsg-response-type> element is no-answer. The <answer-options> element will enable the client to indicate the options of the response that the user can select. In the case of only-one-answer or multiple-answer, each pair of response options consists of a unique message and a text message indicating the meaning of the option. The ID helps the server identify the selection made by the user in response to the system message. Each <answer-options> element may include a <answer-option-id> element and a <answer-option-text> element as a child element. The <answer-option-id> element is an element corresponding to a unique number for identifying a response option, and the <answer-option-text> element is an element for providing free text describing the response option. . If such a child element does not exist, it means that the client will give the user the option to write the response directly.

The <verification> element is used to confirm that the user has read the system message. If this field is present, it indicates that the server requires some kind of acknowledgment to indicate that the user has read the message. . The inclusion of the <verification> element is optional and determined by the server. The <verification> element includes a child element of one of a <verification-text> element and a <verification-uri> element. The <verification-text> element describes the alphanumeric code that the system provides that the user must re-enter in the system message response. The <verification-uri> element describes a URI value that indicates the location of code that the user must enter in the system message response.

The <time-out> element is an element for notifying a user of a duration for which a user response is expected, and includes a condition when a user response to a system message is expected within an arbitrary time / period. If the user does not respond within the stated time / period, the server determines its subsequent actions based on its local policy. The inclusion of the <time-out> element is optional and determined by the server.

 The <restrict-access> element is an element that the server requests the client to block further access to the service until the user responds to the system message. The inclusion of the <restrict-access> element is optional and determined by the server. If the server requests this via the <restrict-access> element, the client should not allow the user any more access to the service. So if the server wants to restrict access to the service until the client responds, the server stays connected and waits for a response until the timeout expires. To determine subsequent actions. The server may resend the system message at timeout, but this also depends on the service provider's policy.

The system message request document will be identified with the MIME content type vnd.example.system-message + xml.

The XML schema of the System Message Request document is shown in Table 2 below.

< !-XML schema for System Message request-><? Xml version = "1.0" encoding = "UTF-8"?><Xs: schema targetNamespace = "urn: oma: params: xml: ns: im: system -message "xmlns: xs =" http://www.w3.org/2001/XMLSchema "xmlns =" urn: oma: params: xml: ns: im: system-message "elementFormDefault =" qualified "attributeFormDefault =" unqualified "><xs: element name =" system-message "><xs:complexType><xs:sequence><xs: element name =" smsg-type "minOccurs =" 1 "><xs:simpleType><xs: restriction base = "xs: string"><xs: enumeration value = "request"/></ xs: restriction></ xs: simpleType></ xs: element><xs: element name = "smsg" minOccurs = "1 "maxOccurs =" unbounded "><xs:complexType><xs:sequence><xs: element name =" smsg-text "type =" xs: string "minOccurs =" 1 "/><xs: element name =" smsg -response-type "minOccurs =" 1 "><xs:simpleType><xs: restriction base =" xs: string "><xs: enumeration value =" no-answer "/><xs: enumeration value =" only- one-answer "/><xs: enumeration value =" multiple-answer "/></ xs: restriction></ xs: simpleType></ xs: element><xs: element nam e = "answer-options" minOccurs = "0" maxOccurs = "unbounded"><xs:complexType><xs:sequence><xs: element name = "answer-option-id" type = "xs: string" minOccurs = "1"/><xs: element name = "answer-option-text" type = "xs: string" minOccurs = "0"/></ xs: sequence></ xs: complexType></ xs: element><xs: element name = "time-out" type = "xs: positiveInteger" minOccurs = "0"/><xs: element name = "restrict-access" type = "xs: empty" minOccurs = "0"/><xs: element name = "verification" minOccurs = "0"><xs:complexType><xs:choice><xs: element name = "verification-text" type = "xs: string" minOccurs = "0"/><xs: element name = "verification-uri" type = "xs: anyURI" minOccurs = "0"/></ xs: choice></ xs: complexType></ xs: element></ xs: sequence>< xs: attribute name = "id" type = "xs: string" use = "required"/></ xs: complexType></ xs: element>

An example of a system message request document including the above elements according to an embodiment of the present invention is described in Table 3 below.

<? xml version = "1.0" encoding = "UTF-8"?> <system-message xmlns = "urn: example: params: xml: ns: application: system-message" xmlns: xsi = "http: // www .w3.org / 2001 / XMLSchema-instance "xsi: schemaLocation =" urn: example: params: xml: ns: application: system-message "> <smsg-type> request </ smsg-type> <smsg id =" abc123 "> <smsg-text> This is first system message </ smsg-text> <smsg-response-type> no-answer </ smsg-response-type> <verification> <verification-text> eryu463jdfh </ verification- text> </ verification> </ smsg> <smsg id = "ghi789"> <smsg-text> Do you wish to continue with the service? </ smsg-text> <smsg-response-type> only-one-answer </ smsg-response-type> <answer-options> <answer-option-id> 1 </ answer-option-id> <answer-option-text> Agree </ answer-option-text> </ answer-options > <answer-options> <answer-option-id> 2 </ answer-option-id> <answer-option-text> Disagree </ answer-option-text> </ answer-options> <verification> <verification- uri> http://mysite.mydomain.com </ verification-uri> </ verification> <timeout> 60 </ timeout> </ smsg> <smsg id = "def456"> <smsg-text> This is third system message </ smsg-text> <smsg-response -type> multiple-answer </ smsg-response-type> <answer-options> <answer-option-id> 1 </ answer-option-id> <answer-option-text> first option to user </ answer- option-text> </ answer-options> <answer-options> <answer-option-id> 2 </ answer-option-id> <answer-option-text> second option to user </ answer-option-text> </ answer-options> <answer-options> <answer-option-id> 3 </ answer-option-id> </ answer-options> <verification> <verification-text> 4dfjk9067fh </ verification-text> </ verification> <timeout> 90 </ timeout> <restrict-access /> </ smsg> </ system-message>

Next, the structure of the system message response document will be described.

A system message response document is an XML document that must be well-formed and valid. System message response documents are written based on XML 1.0 and use UTF-8 encoding. The present invention defines and uses an XML namespace to uniquely identify a System Message Response document or a fragment of this document. The namespace URI for elements defined by the present invention is one URN using the namespace identifier 'example'. These URNs are as follows:

urn: example: params: xml: ns: application: system-message

The system message response document starts with the <system-message> root element, which is the <smsg-type> element, the <smsg> element, the <answer> element, the <answer-id> element, and the <answer-text> element. Element, may contain a <verification> element.

Table 4 shows the definition of each element.

Element name What is described in the element smsg-type Indicates whether it is a "request" or a "response" smsg Unique number to associate the request with a response answer List of selected answers answer-id Identifies the user selected answer option answer-text Optional free text answer verification Confirm that the user has read the system message

Referring to Table 4 above, each element will be described in detail.

The <smsg-type> element indicates that the system message is in the form of a response, which means that it is from the client to the server.

The <smsg> element is an element that contains a value contained in the 'id' attribute of the <smsg> element of the system message request, and helps to find a match between the request and the response on the server. The <smsg> element also helps correlate responses with each other when there are two or more system messages sent in one message to reduce the overhead of message and signaling.

The <answer> element is an element representing a user selection from a list of response options, and may include a plurality, and is a selection between a set of response options defined in the system message request. Each <answer> element may include a <answer-id> element as a child element. If the value of the <smsg-response-type> element in the system message request is a plurality of responses, there may be a plurality of <answer-id> elements. This allows the user to send multiple responses to one request using the same message. Using only IDs reduces the payload of the message. In addition, each <answer> element may include a <answer-text> element as a child element together with a <answer-id> element when there is a free text response input by the user. The answer response may facilitate the service provider's decision on various factors such as the level of service to be granted to the user and password reset, new registration, billing, features, and the like.

The <verification> element is used to confirm that the user has read the system message. For example, the user can input the code appearing in the system message request so that the server can confirm that the user has read the system message. To make it possible. Alternatively, the <verification> element may be code that exists at a location described by a particular URI, as mentioned in the system message request. If the validation from the response provided by the user fails, then the server policy will determine for further action. For example, the server may resend the system message without allowing the server to grant further access to the service.

The system message response document will be identified by the MIME content type vnd.example.system-message + xml.

The XML schema of the System Message Response document is shown in Table 5 below.

<!-XML schema for System Message request-> <? Xml version = "1.0" encoding = "UTF-8"?> <Xs: schema targetNamespace = "urn: oma: params: xml: ns: im: system -message "xmlns: xs =" http://www.w3.org/2001/XMLSchema "xmlns =" urn: oma: params: xml: ns: im: system-message "elementFormDefault =" qualified "attributeFormDefault =" unqualified "> <xs: element name =" system-message "> <xs: complexType> <xs: sequence> <xs: element name =" smsg-type "minOccurs =" 1 "> <xs: simpleType> <xs: restriction base = "xs: string"> <xs: enumeration value = "response" /> </ xs: restriction> </ xs: simpleType> </ xs: element> <xs: element name = "smsg" minOccurs = "0 "maxOccurs =" unbounded "> <xs: complexType> <xs: sequence> <xs: element name =" answer "minOccurs =" 0 "maxOccurs =" unbounded "> <xs: complexType> <xs: sequence> <xs: element name = "answer-id" type = "xs: string" minOccu rs = "0" /> <xs: element name = "answer-text" type = "xs: string" minOccurs = "0" /> </ xs: sequence> </ xs: complexType> </ xs: element> <xs: element name = "verification" minOccurs = "0" maxOccurs = "unbounded"> <xs: complexType> <xs: sequence> <xs: element name = "verification-text" type = "xs: string" minOccurs = "0" /> </ xs: sequence> </ xs: complexType> </ xs: element> </ xs: sequence> <xs: attribute name = "id" type = "xs: string" use = "required" /> </ xs: complexType> </ xs: element> </ xs: sequence> </ xs: complexType> </ xs: element> </ xs: schema>

An example of a system message response document including the above elements according to an embodiment of the present invention is described in Table 6 below.

<? xml version = "1.0" encoding = "UTF-8"?> <system-message xmlns = "urn: example: params: xml: ns: application: system-message" xmlns: xsi = "http: // www .w3.org / 2001 / XMLSchema-instance "xsi: schemaLocation =" urn: example: params: xml: ns: application: system-message "> <smsg-type> response </ smsg-type> <smsg id =" abc123 "> <verification> <verification-text> eryu463jdfh </ verification-text> </ verification> </ smsg> <smsg id =" ghi789 "> <answer> <answer-id> 1 </ answer-id> < / answer> <verification> <verification-text> 354agr67h </ verification-text> </ verification> </ smsg> <smsg id = "def456"> <answer> <answer-id> 1 </ answer-id> < answer-id> 3 </ answer-id> <answer-text> tom </ answer-text> </ answer> <verification> <verification-text> 4dfjk9067fh </ verification-text> </ verification> </ smsg> </ system-message>

The transmission and reception of the system message will be described with reference to FIGS. 1 and 2 as follows. 1 is a diagram illustrating a process in which a client receives a system message request from a server, and FIG. 2 is a diagram illustrating a process in which a client transmits a system message response to a server. First, a process of transmitting a system message request will be described with reference to FIG. 1.

When the server X 130 determines that a system message needs to be transmitted to the client X 110 according to the current communication environment, the server X 130 creates a SIP request message, that is, a system message request, and transmits it to the SIP / IP core 120. . At this time, the Request-URI of the SIP request message includes the address of the client X 110, and the Accept-Contact header of the SIP message header includes a feature tag '+ g.application.smsg'. The Content-Type field of the message header includes a MIME content type of application / vnd.example.system-message + xml to indicate that the message body includes content related to a system message, and the message body of the SIP message. Consists of an XML document containing the content associated with the system message request.

An example of such a SIP request message is shown in Table 7.

Request-URI Sip: UserX@networkX.net SIP HEADERS P-Asserted-Identity: "Server X" <sip: ServerX@networkX.net> Accept-Contact: *; + g.application.smsg; require; explicit Content-Type: application / vnd.example.system-message + xml XML MIME BODY <? xml version = "1.0" encoding = "UTF-8"?> <system-message xmlns = "urn: example: params: xml: ns: application: system-message" xmlns: xsi = "http: // www .w3.org / 2001 / XMLSchema-instance "xsi: schemaLocation =" urn: example: params: xml: ns: application: system-message "> <smsg-type> request </ smsg-type> <smsg id =" ghi789 "> <smsg-text> Do you wish to continue with the service? </ smsg-text> <smsg-response-type> only-one-answer </ smsg-response-type> <answer-options> <answer -option-id> 1 </ answer-option-id> <answer-option-text> Agree </ answer-option-text> </ answer-options> <answer-options> <answer-option-id> 2 < / answer-option-id> <answer-option-text> Disagree </ answer-option-text> </ answer-options> </ smsg> </ system-message>

Meanwhile, in step 203, the SIP IP / Core X 120 refers to the SIP request message received from the server X 130 and transmits the information to the client X 110 with reference to the information stored in the registration step. The client X 110 displays the received SIP request message, that is, the system message request, in step 205 and provides it to the user. In step 207, the client X 110 transmits a SIP 200 “OK” response to the SIP / IP Core X 120 to confirm that a SIP request message, that is, a system message request has been received. The SIP 200 "OK" response is transmitted to the server X through a signal processing path, and may be configured as shown in Table 8 below.

SIP HEADERS P-Asserted-Identity: "User X" <sip: UserX@networkX.net>

The SIP / IP core 120 receiving the SIP 205 "OK" response transmits the SIP 200 "OK" response to the server X 130 in step 209. The server X 130 receives the SIP 200 "OK" response to confirm that the client X 110 has received a system message request.

Next, the client X 110 receives the SIP request message, that is, a system message request, and then transmits a system message response thereto through a newly configured SIP response message according to the present invention with reference to FIG. 2. Explain. As shown in FIG. 2, the client X 110 transmits a SIP response message for the SIP request message received in the process of FIG. 1 to the SIP / IP Core X 120. At this time, the Request-URI of the SIP response message includes the server X 130 address, and the Accept-Contact header of the SIP message header includes a feature tag + g.application.smsg. The Content-Type field of the message header stores a MIME content type of application / vnd.example.system-message + xml to indicate that the message body includes content related to a system message, and the message of the SIP message. The body consists of an XML document containing the content associated with the system message response. An example of this is shown in Table 9.

Request-URI sip: ServerX@networkX.net SIP HEADERS P-Preferred-Identity: "User X" <sip: UserX@networkX.net> Accept-Contact: *; + g.application.smsg require; explicit Content-Type: application / vnd.example.system-message + xml XML MIME BODY <? xml version = "1.0" encoding = "UTF-8"?> <system-message xmlns = "urn: example: params: xml: ns: application: system-message" xmlns: xsi = "http: // www .w3.org / 2001 / XMLSchema-instance "xsi: schemaLocation =" urn: example: params: xml: ns: application: system-message "> <smsg-type> response </ smsg-type> <smsg id =" ghi789 "> <answer> <answer-id> 1 </ answer-id> </ answer> <verification> <verification-text> 354agr67h </ verification-text> </ verification> </ smsg> </ system-message >

The SIP / IP Core X 120 transmits the SIP response message received in step 303 to the server X 130 based on the feature tag + g.application.smsg in the Accept-Contact header. The server X 130 receives the response of the client X 110 to the system message request in step 305 by receiving the SIP response message. Thereafter, in step 307, the server X 130 transmits a SIP 200 "OK" response to the SIP / IP Core X 120, which is configured as shown in Table 10 below.

SIP HEADERS P-Asserted-Identity: <sip: ServerX@networkX.net>

Thereafter, the SIP / IP Core X 120 transmits a SIP 200 “Ok” response to the client X 110 in step 308.

The present invention adds a feature tag indicating a system message and a MIME content type to a message header of a SIP message, and accordingly includes an XML document including content related to the system message in a message body, thereby providing a system message using a SIP message. send. At this time, the SIP message may be realized through the MESSAGEmethod, MSRP SEND method, SIP INFO methods. 3 to 5 illustrate a system message transmission process corresponding to each SIP method. 3 is a diagram illustrating a system message transmission process according to a general SIP MESSAGE method, FIG. 4 is a diagram showing a system message transmission process according to an MSRP SEND method, and FIG. 5 is a diagram showing a system message transmission process according to a SIP INFO method. to be.

In the SIP MESSAGE method, as shown in FIG. 3, the server 20 configures a system message request for providing information or an alert, an approval / rejection request, and a plurality of response requests in step 11 according to the XML schema of Table 2 above. . That is, the server 20 may include the <smsg-type> element, the <smsg> element, the <smsg-text> element, the <smsg-response-type> element, the <answer-options> element, the <verification> element, and the <time- An out> element and a <restrict-access> element are used to compose the content included in the system message request, and are transmitted to the client 10 in step 13 using the SIP MESSAGE method. The client 10 displays the system message request received in step 15 separately from the general message, and controls the user's access to a specific service when requested by the system message request. The client 10 transmits a 200 "OK" response to the server 20 in step 17. If necessary, the client 10 configures the response message to the system message request in step 19 according to the XML schema of Table 5 above within the time limit provided in the system message request. That is, the client 10 may be included in the system message response using the <smsg-type> element, the <smsg> element, the <answer> element, the <answer-id> element, the <answer-text> element, and the <verification> element. The content is configured and transmitted to the server 20 in step 21 using the SIP MESSAGE method. The server 20 recognizes the transmitted response message, confirms that the user has read the system message, and sends a 200 "OK" response to the client 10.

In the MSRP SEND method, as shown in FIG. 4, the server 20 configures a system message request for providing information or an alert, an approval / rejection request, and a plurality of response requests in step 31 according to the XML schema of Table 2 above. . That is, the server 20 may include <smsg-type> elements, <smsg> elements, <smsg-text> elements, <smsg-response-type> elements, <answer-options> elements, <verification> elements, and <time- An out> element and a <restrict-access> element are used to construct the content included in the system message request, and the MSRP SEND is transmitted to the client 10 in step 33. The client 10 displays the system message request received in step 35 separately from the general message, and controls the user's access to a specific service when requested by the system message request. The client 10 transmits a 200 "OK" response to the server 20 in step 37. If necessary, the client 10 configures the response message to the system message request in step 39 according to the XML schema of Table 5 above within the time limit provided in the system message request. That is, the client 10 may be included in the system message response using the <smsg-type> element, the <smsg> element, the <answer> element, the <answer-id> element, the <answer-text> element, and the <verification> element. The content is composed and transmitted to the server 20 in step 41 using MSRP SEND. The server 20 recognizes the transmitted response message, confirms that the user has read the system message, and sends a 200 "OK" response to the client 10.

In the SIP INFO method, as shown in FIG. 5, the server 20 configures a system message request for providing information or an alert, an approval / rejection request, and a plurality of response requests in step 51 according to the XML schema of Table 2 above. . That is, the server 20 may include <smsg-type> elements, <smsg> elements, <smsg-text> elements, <smsg-response-type> elements, <answer-options> elements, <verification> elements, and <time- Using the out> element and the <restrict-access> element, the content included in the system message request is envisioned and transmitted to the client 10 in step 53 using the SIP INFO method. The client 10 displays the system message request received in step 55 separately from the general message, and controls the user's access to a specific service when requested by the system message request. The client 10 transmits a 200 "OK" response to the server 20 in step 57. If necessary, the client 10 configures the response message to the system message request in step 59 according to the XML schema of Table 5 above within the time limit provided in the system message request. That is, the client 10 may be included in the system message response using the <smsg-type> element, the <smsg> element, the <answer> element, the <answer-id> element, the <answer-text> element, and the <verification> element. The content is configured and transmitted to the server 20 in step 61 using the SIP INFO method. The server 20 recognizes the transmitted response message, confirms that the user has read the system message, and sends a 200 "OK" response to the client 10.

As taught by the foregoing description and the accompanying drawings, other control methods and devices may be derived from combinations of the various methods and devices of the present invention, and such modifications should also be considered to be within the scope of the present invention. It will be apparent to those skilled in the art. Moreover, the description of such combinations and variations is omitted here. It should be appreciated that the host device for storing the application includes, but is not limited to, a computer, a mobile communication device, a mobile server, or other multi-function terminal device.

As described above, the present invention adds a feature tag indicating a system message and a MIME content type of a system message to a message header of a SIP message, and accordingly, includes an XML document describing content related to the system message in a message body of the SIP message. As the system message is transmitted using the SIP message, the system message can be distinguished from normal messages when the system message is transmitted using SIP, and the server can identify a response to the system message received from the client. And if the server is expecting a response from the client, it can wait for a specified period of time and provide the user-friendly service level access control required from the server. The server can also send system messages to clients, receive a response from the client, determine subsequent actions based on the service provider's policies, and can be applied to the SIP MESSAGE method, MSRP SEND method, and SIP INFO method. Do.

Claims (12)

A method of transmitting a system message using a session initiation protocol, The server adds a feature tag in the message header of the Session Initiation Protocol (SIP) message and a multi-purpose internet mail extension (MIME) content type indicating that the message body includes content related to the system message. Including a system message request XML (eXtensible Markup Language) document describing content related to the system message request in a body, constructing and transmitting a system message request corresponding to the current situation; A client receives the system message request, adds the feature tag and the MIME content type to a message header of a SIP message in response to the received system message request, and responds to the system message request in the message body; And including a system message response XML document describing related content, constructing a system message response, and transmitting the system message response to the server. The method of claim 1, wherein in the process of constructing and transmitting the system message request, the server constructing the system message request corresponding to the current situation includes providing information, providing an alert, and approving / rejecting an arbitrary service. And a system message corresponding to any one of a request and a plurality of response requests for any service. The method of claim 2, wherein the process of constructing and transmitting the system message response comprises analyzing the received system message request when the client receives the system message request, and distinguishing from the general SIP message if the feature tag is included. The method further comprises the step of displaying the system message transmission method. The system message transmission as claimed in claim 3, wherein, in the process of constructing and transmitting the system message response, the client configures the system message response if the content requesting a response is included in the received system message request. Way. The method of claim 4, wherein the system message request and the system message response are transmitted according to any one of a SIP MESSAGE method, an MSRP SEND method, and a SIP INFO method. The method of claim 5, wherein the feature tag is included in an Accept-Contact field of the message header, and the MIME content type is included in a Content-Type field. The method of claim 6, wherein the feature tag is a + g.application.smsg tag and the MIME content type is vnd.example.system-message + xml. 7. The method of claim 6, wherein the system message request XML document and the system message response XML document start with a <system-message> element as a root element. 10. The system of claim 8, wherein the system message request XML document includes a <smsg-type> element indicating that the system message is a request system message and an individual number for associating a response to any system message request. An <smsg-text> element containing an element, any information to be sent to the client, a <smsg-response-type> element containing the type of response to request from the client in response to the system message request, and the <smsg- Inclusion is determined according to the type of response included in the response-type> element, and the <answer-options> element including the specific content and the identifier of the response and a method for determining whether the user confirms the system message request are included. A <verification> element containing a code and a system message response to the system message request And a <restrict-access> element for requesting the client to block other connections associated with the service until the user responds to the system message request. How to send system messages. 10. The method of claim 9, wherein the <smsg-response-type> element includes a non-response that does not request a response from the user, a one-time response that allows the user to select one of two different responses, and a plurality of user responses. Includes at least one response type from among the plurality of requesting responses, The <answer-options> element is not included in the system message request XML document when the value of the <smsg-response-type> element is non-response, and corresponds to each response when the one-time response or one of the plurality of responses is one. A child element containing a <answer-option-id> element including an identifier to the identifier and a <answer-option-text> element including a text indicating the specific meaning of each response, The <verification> element includes a <verification-text> element including an alphanumeric code to be input by a user in response to a system message request, and a <verification-uri> element including a URI of the alphanumeric code. System message transmission method comprising a child element. The method of claim 10, wherein the <time-out> element, the <restrict-access> element, and the <verification> element are selectively included in the system message request XML document. 12. The system of claim 11, wherein the system message response XML document includes the <smsg-type> element, the <smsg> element, a <answer> element including a user's response to the system message request, and the system message. And the <verification> element containing a numeric string input from a user corresponding to the alphanumeric string included in the <verification> element of the request.

Images