KR20180023917A - Method for supporting the matching between a teacher and a student of telephone lessons - Google Patents

Abstract

The present invention relates to a method of supporting a real-time lecture on a random topic through a telephone. When a lecturer expresses a will to provide a lecture on a preregistered list of topics viable for lecture through a terminal, an expected quality of media traffic between the terminal of lecturer and an internet telephone server is measured, quantified, and stored for the internet telephone-based method. A student who wants to receive a real-time lecture on a certain topic can select a lecturer according to his/her preference such as the expected quality of telephone call or the name of the lecturer from the list of available lecturers on the topic. After selecting and requesting a real-time lecture along with inputting simple additional information such as the topic or lecture time, the selected lecturer accepts after confirming the additional information. In the case of the internet telephone-based method, before establishing an actual telephone connection, the quality of media traffic between the lecturer and student is measured. If the quality is below a certain reference level, the lecturer and student are notified of this fact. If the quality satisfies the certain reference level or the lecturer and student agree, the telephone connection between the lecturer and student is supported for a real-time lecture. For a landline telephone, only the actual telephone connection between the lecturer and student is supported.

Description

A method of supporting real-time matching between instructor and lecturer of telephone lecture.

The present invention relates to a lecturer who is willing to provide a lecture in real-time conversation form over the telephone on a subject of a specific field registered by a lecturer member at the time of providing a telephone lecture service and a lecturer The present invention relates to a telephone lecture system including a method for real-time matching between learners, and includes a method of expressing intention to provide a real-time lecture through a telephone terminal by a lecturer, And includes a method of including a call quality prediction index for each lecturer when retrieving a possible lecturer list, and also includes a method of notifying the instructor of the request of the lecture when the lecturer selects the lecturer.

Internet telephony using the SIP protocol is relatively inexpensive or free under certain circumstances, compared to conventional analog telephony, and the SIP protocol itself provides tremendous scalability for adding new features or services as compared to analog telephony services, It is very easy to construct an independent IP telephone network by using a unique telephone number system such as an extension number by constructing an Internet telephone server by utilizing this IP PBX, etc. In case of a call between extensions, there is no call fee, In analogue systems, it can be physically restricted within a specific building, but it can exist anywhere in the world in IP mode. Realizing the real-time matching method between the lecturer and the learner by constructing the system of the present invention by taking advantage of the economical efficiency in the construction and provision of the service, the scalability of the SIP protocol, and the construction of the own telephone network without space limitation. However, in comparison with a circuit switched analog telephone using a channel in which a fixed bandwidth is pre-allocated, a call quality is always a problem in an Internet protocol based telephone using a packet exchange method. In the present invention, And provide them to students to choose the best instructor, thereby providing some solution to the call quality problem.

Japanese Patent Application Laid-Open No. 2008-129081 Dialogue Lecture Support System

Through the present invention, a lecturer who is willing to provide a real-time lecture over the telephone and a lecturer who is willing to lecture outline the method of providing a lecture at a desired place and requesting the lecture at a desired time out of time and place restrictions do.

In order to solve the above problems, the present invention enables a member who can perform a role of a lecturer to perform a role of a lecturer at a certain time and place through a lecture expression of a real-time lecture, (Lecture ID, lecture topic, lecture time) to the lecturer when the lecturer requests the lecture by choosing the lecturer. So that the lecturer can refer to it and provide the convenience to refuse lecture in an emergency situation.

If you use a telephone server, you can use the existing phone server system by using feature code or ARS, or you can use the extensibility of SIP protocol to make a very simple modification to general purpose SIP client program and Internet phone server program Or function, and if the service providing server is used, it is implemented using HTTP or its own protocol.

The call quality prediction is measured in the interval between the Internet telephony server and the instructor terminal so that the learner can provide the instructor information together with the instructor list when searching the lecturer list on a specific field topic so that the learner can refer to the lecturer selection.

The delivery of the lecture request of the learner utilizes the scalability of the SIP protocol when the Internet telephone server is used, and the HTTP or the self protocol is used when the service providing server is used.

Through the present invention, in the case of the telephone English service, the lecturer or the learner can provide a lecture at a desired time and place, rather than a predetermined schedule, and can make a request.

If you are connected to the internet, whether it is wired or wireless, you can choose an instructor according to your preference at any time and place,

In addition, Internet instructors can provide lectures at any time and place if only Internet, whether wired or wireless, is connected. Of course, telecommuting is 100% possible and it can be freed from the burden of the call charges by utilizing the internet phone.

In the case of the existing Internet telephone, the communication quality is a problem. In the present invention, by providing a method of predicting the communication quality, the optimum matching is supported, and thus, a desired purpose can be achieved at a lower cost in terms of the student .

In the system of the present invention, a member is basically a student who is a student and capable of providing a lecture to an unspecified number of subjects in a specific field, stores related topic field information in a member information DB, Providing lectures Providing lectures by expressing the intention to teach lectures When a learner performs a lecturer role, the lecturer list is included in the lecturer list when a lecturer searches for a lecturer list on a specific field topic. If the lecturer requests lecture, . If you are not willing to provide lectures, you can take the role of a student.

1 illustrates a service configuration block for implementing a real-time matching method between a lecturer and a learner of a telephone lecture according to an embodiment of the present invention. The telephone server may be an Internet telephone server of the SIP type and a general telephone server of the analog type in some cases.
FIG. 2 is a flow chart of a first half of an entire message transmission / reception procedure between service configuration blocks in FIG. 1 according to an exemplary embodiment of the present invention. A lecturer terminal becomes a callable state through a registration process of a SIP protocol and a call quality prediction process between an instructor terminal and an Internet phone server After the lecture is given, the lecturer provides lecture presentation step of present lecture, lecturer list which lecturer can lecture about the specific field subject which lecturer wants to take lecture, , Lecture topic, and student ID), and in the case of the lecturer, the instructor confirms the lecture request fact information and the lecturer accepts the lecture. Both parts of the instructor's lecture presentation and lecturer's lecture request information are implemented using the SIP protocol (event state change, event notification request, event notification response).
FIG. 3 is a flow chart of the second half of the entire message transmission / reception procedure between service configuration blocks in FIG. 1 according to an embodiment. In the case where the instructor accepts a lecture request from a learner, The call quality prediction process is performed between the instructor terminal and the learner terminal. The following procedure shows the call forwarding method of Internet telephony using the SIP protocol of IETF. When the Internet telephony server connects the call to the instructor who has accepted the lecture, if it succeeds, Mediate the telephone connection between the instructor and the learner through the standard call transfer process.
FIG. 4 is a flow chart of a second half of the entire message transmission / reception procedure between service configuration blocks in FIG. 1 according to an embodiment, in which a lecturer rejects a lecture request of a lecturer.
FIG. 5 shows a procedure of performing lecture presentation by a lecturer through an ARS (Automatic Response System) implemented in a telephone server.
FIG. 6 shows a procedure of performing a lecture provision expression by a lecturer through a feature code assigned to a telephone server for a corresponding purpose.
FIG. 7 shows a process of adding an extension header or adding a content type to a SIP request message of a SIP transaction and expressing content of the corresponding type by performing a lecture presentation by a lecturer.
FIG. 8 illustrates a process of accepting or rejecting a lecturer's instruction through HTTP using a lecture providing instruction by a lecturer, a lecture requesting lecture notification by a lecturer, and a lecture requesting notification by a lecturer.
FIG. 9 shows a process in which a lecture request notification of a learner is performed by adding an extension header or adding a content type to a SIP Request's SIP Request message and recording the content of the corresponding type.
FIG. 10 illustrates a process of accepting or rejecting a lecturer's lecture through a protocol using a TCP or a UDP packet in response to a lecture presentation by a lecturer, a lecture request notification by a lecturer, and a lecture request notification .

In a procedure for realizing a matching operation of a system implementing a method for supporting real-time matching between a lecturer and a lecturer in a telephone lecture,

As a lecturer, a member who intends to provide a lecture to an unspecified number must include a topic of a special field at the time of membership registration and store lecturer information including the remaining general personal information in the service providing server 3, (1) performs a SIP registration process to the Internet telephone server (2), and if a call becomes available, predicts and quantifies the call quality between the Internet telephone server (2) and the instructor terminal (1) The call quality prediction index can then be periodically measured and continuously updated.

The lecturer informs the telephone server 2 or the service providing server 3 whether the lecturer terminal 1 intends to provide a lecture that changes in real time. Either way, the information is shared between the two servers. When the learner retrieves the present lecturer list through the service providing server 3, the lecturer is added to the list and deleted according to the lecturer's intention to provide the lecture.

Through the process of (1) of FIG. 2, the lecturer will present the current lecture provision expression. Implement using SIP PUBLISH message defined in IETF RFC3903 standard. An event already defined in RFC 3856 of the IETF is a message used when a terminal or a SIP object requests a change of status information about a specific event. Presence (whether the current object is logged in and is in a callable state or an IP address of the terminal Of attendance information). An arbitrary event is added to implement the present invention. For example, if you add a lecture event and send a <provice> yes </ provide> xml element to the body of your publish message, you promise each other that the instructor will be willing to lecture. For presence events, the body of the message body (PIDF, Presence Information Data Format) is defined in RFC 3863. If you want to express lecture intention through initial publish message and extend the lecture provision state through refresh publish message and change from willing lecture to no lecture, you can express that you do not intend to lecture through remove publish message.

If there is a lecturer requesting the lecture through the process of (2) of Fig. 2, the user is requested to notify the information. Implement using the SIP SUBSCRIBEH message defined in the IETF RFC3265 specification. This message is used when the terminal or the SIP object requests to notify itself of the change of the status information about a specific event. The already defined event is presence (whether or not the current object is logged in and ready to talk Or attendance information such as the IP address of the terminal). An arbitrary event is added to implement the present invention. For example, if a lecture (an event related to a lecture) is added and a SUBSCRIBE message is transmitted, a lecture < requester > is added to the body part of the NOTIFY message, Student ID </ requester> <time> 30 minutes </ time> <subject> At the airport, add the </ subject> </ lecture> xml element and the teacher will notify you of this and send the subject If you intend to provide lectures to a specific student ID for 30 minutes, you will accept and provide lectures. Since the lecture corresponding to the specific event is a private event added for the service of the present invention, if the appointment is made between the Internet telephone server 20 and the instructor terminal 10 in advance, the process of (1) in FIG. 2 is skipped and the subscribe message You can also use it as a tool to express when you are willing to provide.

Through the process of (3) in FIG. 2, the Internet telephone server 20 delivers to the service providing server 30 a list of instructors who are willing to provide lectures through a protocol other than SIP or HTTP. Of course, it can be implemented with SIP or HTTP, but it has no advantage over using its own protocol, so it can be implemented in a way preferred by the developer. In the service configuration block of FIG. 1, the Internet telephone server 2 and the service providing server 3 are logically separated concepts, and they can be physically mounted on the same hardware server and can be separated separately. The process of (3) is the interaction between the Internet telephony server and the service providing server, and it is continuously performed so that all the lecturers' present lectures will be provided, the status during the lecturing, Field themes are shared with each other.

2, the learner who wishes to take a telephone lecture can check the list of lecturers who are willing to lecture on the subject of the specialization through the Internet browser from the terminal 40, and the lecturer list And the quality of call prediction index. The priority of the instructor list can be given to the instructor as a preferred instructor if the instructor who has lecture experience from the specific instructor is designated in advance as the preferred instructor. Or if the average access time of the instructor matches the average access time of the learner, the instructor may be given a higher priority to ensure consistency of the lecture. Instructors with high call quality prediction indexes may be given high priority. Whether the instructor is currently on the call (during the course) may be provided as additional information for the instructor on the instructor list, or the instructor may be removed from the instructor list. In both cases, the lecturer can not request lectures to the lecturer. Students select a specific instructor according to their preference and then ask the lecturer for a lecture. An example using the http protocol for the process of (4), which may be developed by replacing an application using its own protocol.

2, the Internet telephone server 20 passes additional information such as a learner ID, a lecturer ID selected by the learner, a lecture time, and a lecture topic from the service providing server 30.

2, the Internet telephone server 20 transmits the information received from the service providing server 30 to the instructor terminal 10 through the process of (5). At this time, the instructor terminal 10 creates a SIP NOTIFY message as a response message according to the scheme requested by the instructor terminal 10 through the SIP SUBSCRIBE message, and the event and the message body of the message are transmitted to the lecture The instructor terminal 10 as the xml element (message body) at the <airport> <subject> and <lecture> <requester> learner ID </ requester> <time> . The event name and message body are examples only to show examples, and can be modified to any other name and format. When the instructor terminal 10 receives the NOTIFY message, it notifies the instructor through the message box or the like, receives the acceptance or rejection request, and when the instructor terminal 10 accepts the NOTIFY message, the instructor terminal 10 delivers the 200 OK message to the Internet phone server 20, Allows a call connection to continue, and if rejected, pass a SIP error message (eg 603 Declined) to pass the rejection. However, if such an error message is transmitted, the subscription established by using the subscribe message through the process of 2 in FIG. 2 is canceled. Therefore, when it is desired to receive a lecture request from another learner, The process of (2) of FIG. In order to successfully complete the SIP transaction, a SIP Response message is transmitted in a timer F (non-INVITE transaction timeout timer) having a value of 64 times (32 seconds) of t1 having a value of 500 ms as default among sip timers specified in RFC 3261 . Therefore, after receiving the NOTIFY message, a message box is displayed to notify the lecturer, and after waiting for the lecturer's acceptance or rejection response within 32 seconds, if the lecturer does not respond, the lecturer automatically rejects the response (eg 603 Declined) .

If the lecturer 11 accepts the lecture request through the process of (7) in FIG. 3, the Internet telephone server 21 notifies the service providing server 31 of the fact through its own protocol and transmits an http 200 ok message or AJAX (Asynchronus javascript XML) will be notified to students' Internet browsers. In the case of AJAX, it is used for asynchronous interaction between the service providing server and the learner terminal, and the interaction through AJAX is started in the process of ④ in FIG. 2 in order to be notified to the learner terminal 41 through the process of ⑦ in FIG. There is a need. In the case of utilizing a self-developed application other than an Internet browser, it is notified from the service providing server 31 to the student terminal 41 by its own protocol instead of http. In case of its own protocol, it is composed of ip header + tcp header + lecture request acceptance notification data format or ip header + udp header + lecture request acceptance notification data format.

The quality of the media traffic when the call between the lecturer 11 and the learner 41 is connected through the process of 8 in Fig. 3 is predicted. It may generate an actual RTP packet containing forged DATA and may generate an arbitrary UDP packet including a forged RTP header for ease of implementation. However, for similarity with RTP packets, TCP should be avoided. When an arbitrary UDP packet is generated, a packet exactly the same as the generated packet of the target codec to be used is generated. In the case of ULAW, for example, data of 8000 samples per second is divided into 20-ms intervals (160 bytes * 50 data is transmitted for 1 second), so that 160 bytes of arbitrary data and the size of the RTP header included in the actual RTP packet (I.e., header 12 bytes + extension data included in the basic 12 bytes + codec type), and the UDP packet is received between the instructor terminal 11 and the learner terminal 41 either bidirectionally or one side The other way is to generate virtual traffic. For example, if ULAW is used and quality measurement is performed for 10 seconds, 500 packets are generated. DUMMY data included in each packet includes transmission time of the current system reference. If the instructor terminal 11 generates and transmits the instruction to the instructor terminal 41, the instructor terminal 11 prompts the instructor terminal 11 to retransmit the instruction to the instructor terminal 11 as soon as the instructor terminal 41 receives the instruction. The average RTT value is calculated by comparing the time and the transmission time included in the DUMMY data of the packet, and the average RTT (Round Trip Time) is calculated, the deviation (difference) value between the RTT value and the average RTT value of each packet, These values are used to estimate the call quality using a constant reference value provided through experience. After the call quality prediction process is performed, the numerical value (call quality prediction index) is notified to the learner. If the predicted index falls below a predetermined reference value, the learner provides an opportunity to select another lecturer, or if the learner After accepting the call connection, the process proceeds to the process of connecting the actual call. As in the case of step 7 in FIG. 3, the Internet browser notifies the students through AJAX, and in the case of the self-application, notifies by the self-protocol. Then the student terminal displays a message box and notifies the student of the acceptance or rejection.

3 illustrates a process of establishing an Internet telephone connection between a lecturer and a learner when the lecturer accepts a lecture request through the process of Fig. 3 (i). [0035] The lecturer terminal 11 transmits lecturer information The Internet telephony server 21 directly connects to the lecturer 11 and the learner 41 and uses the SIP call transfer method because the lecturer can directly make a telephone connection manually, Thereby establishing a telephone connection between the instructor 11 and the learner 41. Even in this case, since all the SIP messages are transmitted via the Internet telephone server 21, the start and end points of the telephone connection can be accurately grasped and thus can be used for billing processing.

The case where the lecturer rejects the lecture request through the process of 10 in Fig. 4 is exemplified. 2 is a case in which the lecturer has accepted the lecture request, and the process in Fig. 4 is the case in which the lecturer has rejected the lecture request. And transmits an error message 603 Declined message to the Internet telephone server 22 in response to the SIP NOTIFY message, which is a lecture request notification message of the learner. In the SIP message standard, there are various error messages other than 603, but other error messages can be used as long as they are predefined between the instructor terminal 12 and the Internet telephone server 22.

If the instructor 12 rejects the lecture or the call quality prediction check fails through the procedure of 11 in FIG. 4, the fact is transmitted from the Internet telephone server 22 to the service providing server 32 through its own protocol, The providing server 32 transmits the rejection fact message to the body of the HTTP 200 OK message or notifies the student 42 of the rejection using Asynchronous Javascript XML (AJAX).

If the lecture for the previous lecturer is rejected for other reasons through the process of ⑫ in Fig. 4, but the lecture itself is intended to continue, if there is a lecturer requesting the lecture again by performing the process of ② in Fig. Request the notification of the information again.

The whole process of FIG. 5 shows a method in which the instructor terminal 13 expresses the current lecture intention through the ARS (Automatic Response System) built in the telephone server. In this method, the telephone number to which the instructor terminal 13 requests a call is an extension number allocated in advance to the telephone server 23 in the case of a private telephone network constructed through a PBX or the like, and if the public telephone network Is a telephone number assigned to the telephone server 23 issued by the communication company. When the instructor terminal 13 accesses the ARS in this way, the ARS checks whether the calling number is the number of the instructor terminal 13 stored in the DB together with the subject matter of the specialization, and if not, transmits the corresponding announcement and terminates the call . If the instructor is correct, the instructor terminal 13 receives DTMF input as to whether to provide a current real-time lecture, and terminates the conversation. Thereafter, the instructor list is updated through interworking with the service providing server 33 (if there is an intention to provide the lecture, it is added to the lecturer list, and if there is no intention to provide lecture, the lecturer list is deleted from the lecturer list) The process of providing the instructor list and notifying the instructor 13 when the learner 43 selects the lecturer 13 and connecting the call between the instructor 13 and the learner 43 can be performed through various methods .

The whole process of FIG. 6 shows how the instructor expresses the current lecture intention by pressing a specific feature code such as &quot; * 50 &quot;. In this case, it is divided into a specific feature code for expressing intention to provide lecture, a method for assigning a specific feature code to express that there is no lecture providing intention, and a method for assigning a specific feature code for toggling the two cases have.

In the former case, a specific feature code for expressing the intention to provide lecture, for example, * 50, will be sent out and the call will be terminated. State. Also, if you press a specific feature code to express that you are not willing to give a lecture, for example * 51, the message "No intention to provide lecture is saved" will be sent out and the call will be terminated. Is changed.

In the latter case, when the first instructor state is not in the lecture making process, the lecturer terminal sends a special feature code for toggling the two cases, for example, * 60, "intent to provide lecture is saved" And the status of the instructor is changed to a state in which the lecturer is willing to provide the lecture. Then, if the instructor terminal touches * 60 again, this time, "no wish to provide lecture is saved" message is sent out and the call is ended, and the condition of the lecturer is changed to no lecture provision status. In this way, the condition of the instructor is constantly changing.

Thereafter, the instructor list is updated through interworking with the service providing server 34 (if there is an intention to provide a lecture, it is added to the lecturer list, and if there is no intention to provide lecture, the lecturer list is deleted from the lecturer list) The process of providing the instructor list and notifying the instructor 14 when the learner 44 selects the lecturer 14 and connecting the lecturer 14 and the learner 44 with each other through the various methods described in the present invention .

5 and 6 can be applied not only to the SIP-type Internet telephone but also to the analog-type telephone. In the case of the analog system, the ordinary telephone server (analogue exchange or analog PBX) rather than the Internet telephone server serves only as a telephone server.

The whole process of FIG. 7 shows a method of expressing intention to provide a lecture using SIP Transaction.

First, in the case of SIP message, a method for adding a new function or characteristic in addition to the standardized parameter (header) in the basic protocol is a non-standard parameter (header) starting with X- having an experimental (eXperimental) or extension (eXtension) ), Or non-standard parameters (headers) that start with P- with a private, preliminary, or proprietary meaning. Using this point, a header such as X-Lecture-Intention or P-Lecture-Intention is added to the SIP Request message to express the lecture provision of the lecturer so that the lecturer is willing to provide lecture (yes or no).

An example of using the OPTIONS message, which is a typical out of dialog message used for querying or pinging the Capability of the SIP entity in the SIP protocol, is as follows.

OPTIONS sip: carol@chicago.com SIP / 2.0

Via: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bKhjhs8ass877

Max-Forwards: 70

To: <sip: carol@chicago.com>

From: Alice <sip: alice@atlanta.com>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: sip: alice@pc33.atlanta.com

X-Lecture-Intention: yes

Accept: application / sdp

Content-Length: 0

Second, it is possible to add a CONTENT to the SIP Request message to express the lecture provision of the lecturer, and add a header such as Content-Type: application / lecture-intention to the SIP Request message

Lecture-intention = yes or

Lecture-intention = no

And to express the intention to provide lectures in a way that is described as follows.

An example of using the OPTIONS message is as follows.

OPTIONS sip: carol@chicago.com SIP / 2.0

Via: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bKhjhs8ass877

Max-Forwards: 70

To: <sip: carol@chicago.com>

From: Alice <sip: alice@atlanta.com>; tag = 1928301774

Call-ID: a84b4c76e66710

CSeq: 63104 OPTIONS

Contact: sip: alice@pc33.atlanta.com

Accept: application / sdp

Content-Type: application / lecture-intention

Content-Length: xxx

Lecture-Intention = yes

Thereafter, the instructor list is updated through interworking with the service providing server 35 (if there is an intention to provide a lecture, it is added to the lecturer list, and if there is no intention to provide lecture, the lecturer list is deleted from the lecturer list) The process of providing the instructor list and notifying the instructor 15 when the learner 45 selects the lecturer 15 and connecting the lecturer 15 and the learner 45 with each other through the various methods .

8, the instructor terminal 16 expresses intention to provide a lecture directly to the service providing server 36 via the http protocol without going through the telephone server 26, and sends a lecture request request to the learner terminal 46 via the http protocol And transmits a response of acceptance or rejection to the service providing server 36. [

The lecturer terminal 16 performs the present lecture provision expression through the process of (1) of FIG. When the Http protocol is used, if the lecture intention is expressed through an interface such as a check box in the lecturer-specific personal setting screen, a parameter which is the setting information is stored in the content part (message body) of the Http Post message, 36). Of course, the Http Get method of storing parameters in http url is also possible.

Through the process of (2) of FIG. 8, the telephone server 26 synchronizes the lecture-providing intention with each lecturer from the service providing server 36. In the instructor list for a specific field subject to be provided to the learner, among the lecturers expressing the intention to provide the lecture, only the lecturer not included in the current conversation (during lecture) It is necessary to receive the call status information of the instructor terminal 16 from the telephone server 26. [

8, the learner who wishes to take a telephone lecture can check the lecturer list that he / she is willing to lecture on a topic of his / her current interest through the Internet browser from the terminal 46, If the learner who has lecture experience from a specific lecturer pre-assigns the lecturer as a preferred lecturer, the lecturer can be given a high priority, or if the lecturer's average lecture time and lecturer's average lecture time match, For that reason, the instructor can be given high priority. Students select a specific instructor according to their preference and then ask the lecturer for a lecture. Like the process of (1) in FIG. 8, not only Http Post but also Http Get method is possible. 8 is an example using the http protocol for the process of (3) in FIG. 8, and an application using its own protocol can be developed and replaced as in the process (1) of FIG.

8, the instructor terminal 16 hands over the additional information such as the learner ID, lecture time, lecture topic, etc. from the service providing server 36. [ However, since it is difficult to transmit asynchronous events such as the process of ④ using only the html used in the get request and the ok response of the http protocol, it is transmitted to the instructor terminal 16 through a method such as AJAX (Asynchronous javascript XML, asynchronous JavaScript XML) do. In the case of the AJAX method, the interaction between the lecturer terminal 16 and the service providing server 36 needs to be started when the lecturer terminal 16 expresses intention to provide a lecture through the process of (1) in Fig.

The lecturer terminal 16 expresses the acceptance of the lecture request to the service providing server 36 through the process of Fig. The service providing server 36 transmits the information to the Internet telephone server 26 and the student terminal 46. In the case of the Http method, an interface such as a check box or a button for requesting acceptance or rejection is provided in the process of FIG. 8 ④. When the instructor confirms this, the check box or button is pressed, Body) is stored and transmitted to the service providing server 36. Of course, the Http Get method of storing parameters in http url is also possible. The Internet telephone server 26 performs the process of step 8 of FIG. 3 and step 9 of FIG. 3 on the basis of the lecture provision acceptance intention information so that the telephone connection operation between the lecturer terminal 16 and the learner terminal 46 can be continued do. 8 is a case in which the instructor terminal 16 expresses intention to refuse to provide a lecture to the service providing server 36, and the service providing server 36 notifies the learner terminal 46 of the fact. The process of (6) in FIG. 8 can be performed both in the http post method and in the http get method as in the process of (5) in FIG. The instructor's lecture presentation method and lecture request notification method shown in Fig. 8 can be applied to all telephones including the analog method as well as SIP Internet telephony.

9 shows a method using SIP Transaction in delivering a lecturer selection and a request of a lecturer to the lecturer terminal 17

Through the process of (1) of FIG. 9, the lecturer will present the current lecture provision expression. Using the Http protocol or its own protocol, it is possible to express the intention to provide lectures through the interface such as check box on the lecturer-specific personal setting screen directly to the service providing server or to provide lectures to the Internet phone server through SIP Publish message or general SIP Transaction It can also be expressed. After the lecture providing lecture presentation by the lecturer, the Internet telephone server 27 and the service providing server 37 are interlocked with each other through the process of (2), and the lecturer's willingness to provide lectures is updated by subject. When the instructor terminal 17 is in a busy state (during a lecture), it is also transmitted from the Internet telephone server 27 to the service providing server 37 via the interlocking and is removed from the instructor list transmitted to the learner terminal 47, State.

The learner who wishes to take lectures through the process of (3) in Fig. 9, is instructed from the learner terminal 47 through the Internet browser or his / her own developed application among the lecturers who are willing to lecture on a topic of his / (Lecturer ID, learner ID, lecture time, lecture topic) is transmitted to the Internet telephone server 27 through the process of ④.

9, the instructor terminal 17 receives the lecture request information from the Internet telephone server 27, the lecturer confirms the lecture request information, and instructs the Internet telephone server 27 to accept the lecture request . If the instructor accepts the lecture request, the Internet telephone server 27 transmits the information to the service providing server 37 by performing the process of 7 in Fig. 3, and the service providing server 37 transmits the information to the learner terminal 47). Then, the procedure of ⑧ of FIG. 3 and the procedure of ⑨ of FIG. 3 are performed so that the telephone connection work between the instructor terminal 17 and the student terminal 47 can be continued. If the lecturer rejects the lecture request, the Internet telephone server 27 performs the process of (11) of FIG. 4 to the service providing server 37, and the service providing server 37 transmits the lecture request to the student terminal 47 .

The process of 5 in Fig. 9 shows a method of delivering the lecture request of the learner terminal 47 to the lecturer terminal 17 by the Internet telephone server 27 using SIP Transaction.

First, we use the non-standard parameter (header) that starts with X- or the non-standard parameter (header) that starts with P-, as in the case of lecture provisioning, And transmits it to the instructor terminal. For example, in order to store the lecture request information of the learner, a header such as X-Lecture-Request or P-Lecture-Request is added to the SIP Request message and the learner ID, lecture topic, lecture time is stored as content and transmitted as follows do.

"X-Lecture-Request: Student ID; Lecture topics; Lecture time "or

"P-Lecture-Request: Student ID; Lecture topics; Lecture Hours "

For example

X-Lecture-Request: hong-gil-dong; aerodynamics; 3600sec

And generates a SIP Request message including a header such as &lt; RTI ID = 0.0 &gt;

Second, it is possible to add a CONTENT to store the lecture request information of the learner in the SIP Request message, add a header such as Content-Type: application / lecture-request to the SIP request message, on

"Lecture-Request = Student ID; Lecture topics; Lecture Hours "

And the like.

For example

Content-Type: application / lecture-request

Content-Length: xxx (where xxx is the length of the content recorded in the message body)

And creates a SIP Request message containing a header such as &lt; RTI ID = 0.0 &gt;

Lecture-Request = hong-gil-dong; aerodynamics; 3600sec

And transmits the same content.

In order to successfully complete the SIP transaction, a SIP Response message is transmitted in a timer F (non-INVITE transaction timeout timer) having a value of 64 times (32 seconds) of t1 having a value of 500 ms as default among sip timers specified in RFC 3261 . Accordingly, the instructor terminal 17 receiving the lecture request information of the learner through the OPTIONS message immediately notifies the lecturer in a method of popping up the message box, waits for the lecturer response for a time shorter than the timer F, And sends an error response message such as 603 Decline. If there is no response from the instructor during that time, it automatically sends a 603 Decline error response message. The process after acceptance or rejection of the lecturer is the same as the previous case.

In the case of FIG. 10, the instructor terminal 18 expresses intention to provide lectures to the service providing server 38 through a self-developed protocol, receives the lecture request of the learner terminal 48 via its own development protocol, And transmits a response to the service providing server 38. FIG.

10, the instructor terminal 18 expresses whether or not the current lecture is to be provided. The instructor terminal (18) provides the instructor with an interface such as a button through a self-developed application that is run on the terminal, instructs the instructor to give a lecture such as pressing a button, and provides lectures to ip packets such as tcp or udp And transmits the stored information to the service providing server 38. [

10 is the same as the process of (2) of FIG. 8, and the process of (3) of FIG. 10 is the same as the process of (3) of FIG.

10, the instructor terminal 18 receives the lecture request information including the learner ID, the lecture time, the lecture topic, and other additional information from the service providing server 38. 10, the lecturer selection and lecture request information is stored in an ip packet such as tcp or udp, and is transmitted to the lecturer terminal 18.

The lecturer terminal 18 expresses the acceptance of the lecture request to the service providing server 38 through the process of Fig. The service providing server 38 transmits the information to the telephone server 28 and the student terminal 48. 10, the acceptance information of the lecture request is stored in an ip packet such as tcp or udp, and is transmitted to the service providing server 38. [ 3 and step 9 of FIG. 3 based on the lecture acceptance acceptance information received from the service providing server 38 so that the lecturer terminal 18 and the learner terminal 48 Allow the telephone connection to continue. 10 is a case in which the instructor terminal 18 expresses intention to refuse to provide lectures to the service providing server 38, and in the same way as in the process (1) of Fig. 10, To the service providing server 38, and the service providing server 38 notifies the student terminal 48 of the fact.

The instructor's lecture presentation method and lecture request notification method shown in Fig. 10 can be applied to all telephones including the analog method as well as SIP Internet telephony.

1, 10, 11, 12, 13, 14, 15, 16, 17, 18:
2, 23, 24, 26, 28: telephone server
20, 21, 22, 25, 27: Internet telephone server
3, 30, 31, 32, 33, 34, 35, 36, 37, 38:
4, 40, 41, 42, 43, 44, 45, 46, 47, 48:

Claims (2)

A method for real-time matching between a lecturer and a learner through an Internet telephone server and a service providing server,
Receiving, at the Internet telephone server, a message including pseudo-representation information about provision of a lecture from an instructor terminal;
Analyzing a message including pseudo-representation information about provision of the lecture in the Internet telephone server, and confirming a doctor's expression regarding lecture provision by the lecturer;
Transmitting, in the Internet telephone server, presence / absence information of a lecture providing intention according to a physician expression about providing a lecture of the lecturer to the service providing server;
Providing a list including presence / absence information of the lecture providing intention to a learner terminal of a lecturer who wishes to take a telephone lecture in the service providing server, and receiving a selection from the learner terminal for the list;
Receiving, from the service providing server, additional information related to at least one of the student ID selected by the user, the instructor ID selected by the student, the lecture time, and the lecture subject, and transmitting the additional information to the lecturer terminal; And
In the Internet telephone server, after the instructor terminal confirms the additional information, a telephone connection is established between the instructor terminal and the student terminal
Lt; / RTI &gt;
Wherein the step of receiving the message including the pseudo-representation information related to the provision of the lecture comprises:
Receiving pseudo-representation information about provision of the lecture through a SIP PUBLISH message
Lt; / RTI &gt;
The method of claim 1,
If pseudo-expression information on lecture provision in a designated SIP PUBLISH message is received from the instructor terminal in order to express whether or not the lecturer intends to provide a lecture, reading the pseudo-expression information and confirming whether the lecture is to be provided
/ RTI &gt;
Wherein the step of receiving the additional information and delivering the additional information to the lecturer terminal comprises:
Adding a header to the SIP request message on the SIP Transaction to contain the additional information or including the additional information in a Content (Body part of the SIP message) by adding a Content Type to the instructor terminal
A method for real-time matching between instructors and learners. A method for real-time matching between a lecturer and a learner through an Internet telephone server and a service providing server,
Receiving, at the Internet telephone server, a message including pseudo-representation information about provision of a lecture from an instructor terminal;
Analyzing a message including pseudo-representation information about provision of the lecture in the Internet telephone server, and confirming a doctor's expression regarding lecture provision by the lecturer;
Transmitting, in the Internet telephone server, presence / absence information of a lecture providing intention according to a physician expression about providing a lecture of the lecturer to the service providing server;
Providing a list including presence / absence information of the lecture providing intention to a learner terminal of a lecturer who wishes to take a telephone lecture in the service providing server, and receiving a selection from the learner terminal for the list;
Receiving, from the service providing server, additional information related to at least one of the student ID selected by the user, the instructor ID selected by the student, the lecture time, and the lecture subject, and transmitting the additional information to the lecturer terminal; And
In the Internet telephone server, after the instructor terminal confirms the additional information, a telephone connection is established between the instructor terminal and the student terminal
Lt; / RTI &gt;
Wherein the step of receiving the message including the pseudo-representation information related to the provision of the lecture comprises:
Receiving pseudo-representation information on the provision of the lecture through a SIP Request message on the first SIP Transaction
Lt; / RTI &gt;
The method of claim 1,
If there is a header added to the pseudo-representation information about the provision of the lecture in the SIP Request message on the first SIP Transaction or information indicating intention to provide lecture in the Content (Body part of the SIP message) by Content Type addition, Knowing that there is a doctor, and if there is no information indicating the intention to provide the lecture,
/ RTI &gt;
Wherein the step of receiving the additional information and delivering the additional information to the lecturer terminal comprises:
Adding a header to the SIP request message on the second SIP Transaction in order to contain the additional information or transmitting the Content (Content Body of the SIP message) by adding Content Type to the instructor terminal including the additional information
A method for real-time matching between instructors and learners.

Images