JP2005317001A - Presence server, session control server and packet relay system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make communication between users smoother utilizing terminal type information. <P>SOLUTION: A terminal type is specified based upon information in login and the information is notified by adding it to presence information. Besides, terminals of the same type are connected by an SIP server. Thus, the selection of the communication means of voice communications and a character chat when communication is started and the specification of a calling terminal at a partner terminal are enabled by adding terminal information to the presence information and grasping mutual owned terminals. In addition, detailed status can be grasped from presence information of the same name by grasping presence information and terminal information. Further, in the case of a terminal not provided with a presence function, an SIP server also identifies terminal type information by deputy and can also specify a calling terminal. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an information disclosure setting method.

In recent years, communication technology that incorporates a state grasping technology using a concept called “presence” has been actively developed. “Presence” is a word representing the current state of the user.
By notifying other users of this “presence” in real time, it becomes possible to grasp each other's current state. Among the communication technologies that incorporate presence, IM (Instant Messaging) is a representative communication technology that is currently being implemented. The concept of IM using presence information and the notification method are impp (Instant Meet) of IETF (Internet Engineering Task Force).
The ssaging and Presence Protocol) working group is standardizing. im
The contents standardized by the pp working group are described in Non-Patent Document 1 and Non-Patent Document 2.

Until now, most of the status grasping technology using "presence" is provided as an add-on to the IM service, and the communication protocol used has been expanded to the IM service protocol that each company has built independently. It was in shape. Recently, however, standardization at the protocol level has also been actively carried out. For example, IETF SIMPLE (SIP for Instant Messaging and
The Presence Leveraging Extensions) working group is standardizing a presence information transmission / reception protocol that extends the session connection protocol SIP (Session Initiation Protocol) used in IP telephones. Standard specifications are described in Non-Patent Document 3 and other Internet-Draft. Recently, there is a trend toward integration of services such as IP phones and videophones using SIP by aligning the communication protocol of IM services developed by each company with the SIMPLE standard. There are also moves to develop presence servers that implement the SIMPLE standard and to propose the use of presence in a form separate from IM services.

The IM service is basically premised on a service that is developed by one user and one terminal. For example, it is assumed that User A who uses the IM service has a plurality of terminals, terminal A and terminal A ′, and currently uses the IM service on terminal A. If UserA logs both terminals A and A 'into the IM server at the same time, if the current IM server sends an instant message sent to UserA by another user, UserB, to either terminal A or A' Cannot judge whether it is good.
In the current IM service, when UserA logs in terminal A, if the user tries to log in terminal A ', the server side has a mechanism to prevent double login, such as forcibly logging out terminal A. It is implemented and dealt with.

There is a model that allows this double login when using SIP. However, its function is
It is specialized for IP phones. This is because SIP is a standard originally targeted at IP phones. The following describes the dual login model using SIP.

FIG. 13 is a diagram in which UserB indicated by 312 logs in two SIP phones indicated by 314 and 315 to the SIP server 41. At this time, UserB logs in to SIP server 41 from two terminals 314 and 315.
Send IP REGISTER message. FIG. 5 shows the contents of the REGISTER message. Each terminal is R
The priority order can be specified by specifying the q-value shown at 73 in FIG. 5 during EGISTER transmission. q-value is specified as a number from 0 to 1, and the higher the value, the higher the priority. For example, if the IP telephone terminal 1 indicated by 314 specifies 0.5 for the q-value and the IP telephone terminal 2 indicated by 315 indicates 0.7 for the q-value, the IP telephone terminal 2 indicated by 315 is more q-value. Since the value of is high, the SIP server 41 thereafter handles the IP telephone terminal 2 preferentially. When UserA makes a telephone call to UserB in this state, the SIP server 41 calls the IP telephone terminal 2 having a higher priority among the terminals to which UserB has logged in. The SIP standard manages the double login of the terminal in the above format.

RFC 2778

RFC 2779 RFC 3265 IETF Internet Draft draft-ietf-impp-cpim-pidf-08.txt

In the conventional IM service, the IM server manages only the online / offline status information corresponding to the screen name (user identifier) of the logged-in user, and does not manage the terminal type information. Also, looking at the implementation status of the SIP protocol for each company's IM system, the system is constructed based on a common protocol such as SIP, and the IM system and other services are operated on that system as a common platform. Probability is high. Therefore, in the future, it is expected that various types of terminals such as IM terminals, IP phones, and chat terminals will be connected to the common platform. Furthermore, it is expected that not only a different terminal is connected for each application, but also the same terminal on which a plurality of applications are executed is connected to the common platform. Therefore, when various services using presence information are deployed on the network, it is considered that the inconvenience as shown in FIG. .

FIG. 11 shows that User A who owns the IP telephone terminal 211 is transferred to User B who owns a plurality of terminals 213 to 216.
It is the schematic which showed the case where a telephone call is made via an IP server. It is assumed that User A 211 is connected to a presence server that manages the presence information of each terminal user, and as a result, knows the presence information of User B as indicated by a balloon 217. Each terminal is connected to a SIP server as a connection management server, and the SIP server is executing communication control of each terminal. The solid line shows the transmission path of connection signals exchanged between the terminal and the SIP server.
A line indicated by a one-dot chain line indicates a transmission route of presence information.

In the conventional IM server, the IM server manages a pair of the screen name of UserA and the status information that the UserA terminal 201 is online. When the presence information management method in the IM service is used as it is for the presence server, the presence server manages the user identifier and the corresponding online / offline status information in pairs. UserB is videophone terminal 213, IP phone terminal 214, conference terminal 215, IM
Assume that the terminal 216 is logged in at the same time. Since the presence server manages the user identifier, as shown in the balloon 217, it is possible to notify UserA of the online / offline status information of each terminal of UserB. Therefore, suppose that User A 211 wants to make a call to IP phone terminal B of User B 212 that is currently online. Of course, UserA is Us
If you know all the address information of erB, communication between UserA and UserB is possible. However, since the presence server does not manage the type of each terminal, even if UserA wants to communicate with an IP telephone, it does not know which of the other terminals is an IP telephone terminal. So Us
It is not possible to specify the destination of the actual call from the terminals owned by erB.

In addition, as described in the prior art, there is a model in which one user double-logs multiple terminals in SIP, but this model causes inconvenience. For example, it is assumed that the terminal 315 is not an IP telephone terminal but a terminal other than an IP telephone such as a video telephone terminal or a conference terminal. Since the SIP server 41 is not aware of this, even if UserA calls UserB with an IP phone in this state, the call is made to a terminal other than the IP phone with the highest priority among the terminals to which UserB is logged in.
As a result, the terminal types of UserA's sending terminal and UserB's receiving terminal are different and the call is not established.

In this way, if there is only an IP phone on the SIP network, this double login model is established. However, if there are various terminals other than the IP phone, the model using this q-value causes inconvenience.
In addition, if the types of terminals are diversified due to the common use of protocols, when each terminal uses presence information with the same name, there is a possibility that the presence information alone is insufficient as the amount of information. For example, a balloon 227 in FIG. 11 shows a form in which each terminal commonly uses presence information named “busy”. Each terminal from 213 to 216 indicates that the current terminal has established the current session, and the name of presence information is “calling” in the part called “calling information”
Or suppose that you have registered with one of the values "Waiting". UserA shown in 211 can acquire the current session establishment state of each terminal owned by UserB from the “busy state”.
However, no specific call means is described in the “call information”. Therefore, even if the presence information is acquired and displayed as shown in 227, it is not known by what means the call is actually made. Therefore, the caller UserA shown in 211 can grasp the other party's state only at a resolution of a level that UserB on the receiving side shown in 212 is simply talking to someone and can not contact now. If UserB shown in 212 is actually talking by text chat, it will be interrupted, but it is possible to ring the telephone bell for emergency use. The user has lost one communication timing.

In order to solve the above problem, the present invention extracts the terminal type from the login information at the time of login of each terminal and holds it in the presence server. When notifying the presence information to other users, the terminal information is added to the presence information and notified.

Each user can grasp the type of terminal to which the other user is logged in when communicating. Therefore, the caller who wants to communicate can confirm the communication means that the other user can take now, and can identify the other user terminal that matches the communication means he desires.

Further, by adding the terminal type to the presence information, it is possible to obtain detailed presence information by the terminal type even for the same presence item. For example, even if the presence information with the name “busy state” is “close (busy)”, the user can determine “busy” if the information is from the IP phone. If this information is for the conference terminal, it can be determined as “meeting”, and if this information is for the chat terminal, it can be determined as “chatting”.

In the present embodiment, first, the structure and operation of a presence server and a network for realizing a service using the presence server will be described. Later, the present invention was applied
This section describes the structure and operation of a SIP server using the SIP message routing method.
FIG. 1 schematically shows a functional block diagram of the presence server of the present embodiment. The functional block diagram of FIG. 1 is a diagram showing a logical functional configuration realized in software, but each functional block may be configured by hardware.

FIG. 2 shows how the functional blocks shown in FIG. 1 are realized in hardware. The operations of the various functional blocks shown in FIG. 1 are accommodated in the processing module group 26 of the memory 22 shown in FIG. 2, and the CPU 23 reads and executes the operation procedure during operation. The terminal type information necessary when each processing module operates is stored in the terminal type information management table 30 of the database 24, and the presence information is stored in the presence information management table 31 of the database 24. When the presence server 1 uses these pieces of information, the information is expanded in various information temporary tables 25 in the memory 22 via the timely interface 33 and processed by the CPU 23. The result is written into the database 24 via the interface 33.

FIG. 26 is a flowchart of the processing of the functional block group shown in FIG. Each functional block operates in accordance with the flowchart of FIG.
FIG. 3 is a network diagram of an example of a service using terminal type information, and FIG. 4 is a sequence diagram thereof. In this example, the terminals 45 and 46 owned by UserB shown in 42 of FIG.
And login to the presence server 1. User A shown in 42 and User C shown in 47 are also logged in and are viewing the presence information of the terminals 45 and 46 of User B shown in 43. UserA then calls UserB via IP phone. The overall operation from the extraction of terminal type information to the presence notification with terminal information to other users will be described below using these drawings. In this service example, the presence system is operated using SIP as a communication protocol. However, SIP is not essential for the construction of the presence system, and other protocols can be used. When other protocols are used, the specific message content and detailed sequence are different, but the basic concept remains unchanged. Further, in FIG. 3, the terminals 45 and 46 owned by User B shown in 43 are described as different hardware, but there are cases in which they are handled as different applications 45 and 46 on the same hardware 49 as shown in FIG.

First, at step 51 in FIG. 4, the videophone terminal 45 of UserB logs into the SIP server 41 and the presence server 1. Figure 5 shows the contents of the SIP message when logging in. In SIP, a message using the REGISTER method is sent at login.

Next, the presence server 1 registers the contact address 71 described in the Contact header of the login message shown in FIG. 5 as a terminal address. In step 52, the terminal type information is recognized. Specific processing contents of step 52 will be described with reference to FIG. When the presence server 1 receives a message from the interfaces 13-1 to 13-n in FIG. 1 in step 1291, it starts terminal type extraction processing in step 1292. First, login information transmission / reception unit 12
In step 1293, login information is extracted, that is, contact address 71 is extracted.
Also, in step 1294, the terminal type information extraction / transfer unit 10 sends the User-Agent header value of the login information.
72 is extracted, and the information is transferred to the terminal information management unit 7. In this example, the terminal type is determined from the User-Agent header, but the terminal type may be determined by other methods. For example, a method of extending a unique header or adding a parameter to be added to the Contact header can be considered. An example of assigning parameters to the Contact header is “Contact: <sip: UserA @
A description such as “abc.com>; agent = TVPhone” is conceivable. To change the terminal type determination method, the processing of the terminal type information extraction / transfer unit 10 is changed.

Next, the presence server 1 determines the terminal type from the terminal type information extracted in step 1294 and stores it together with the login information. The specific process will be described. The terminal type information management unit 7 receives the terminal information transferred from the terminal type information extraction / transfer unit 10 earlier. The terminal type information management unit 7 determines the terminal type from the terminal type information received in step 1295. The terminal type information management unit 7 is an input table in the terminal type information management table 30 of the database 34 in FIG.
37 manages the table 101 shown in FIG. The terminal type determination process in step 1295 is performed using this table 101. Note that the table 10 of FIG. 8B managed by 36 of FIG.
6 is a table for outputting presence information, but tables 101 and 106 can be managed on the same table in consideration of use on the database. In this example, the videophone terminal 45 owned by the login terminal UserB has “TVPhone / 1.0 (xxCorp TV Pho
ne) ”is added to the device type. IETF RFC3261 that describes the SIP standard is U
There is a description that the description format of the ser-Agent header value is the same as RFC2616. RFC2616
Then, the description format of the User-Agent header value is “[terminal name] / [version number] ([comment
In step 1295, the terminal type information of the login terminal is determined to be “TVPhone”, which is a value obtained by subtracting the version number and comment from the User-Agent header value 72.
The handling method of the ser-Agent header value may use logic other than that shown in this example. In this example, only “terminal name” is used as the terminal type information, but a pattern in which the “version number” or “comment” part is used as the terminal type information is also conceivable.

In the above process, the terminal type information of the login terminal is determined as “TVPhone”. Next step 1295
Then, in order to determine the actual terminal type from the terminal type information, the input table 101 of the terminal type management table is searched. The search target is login information (User-Agent header) 102, and the search key is terminal type information “TVPhone”. As a result of the search, “TVPhone” can be determined to be a videophone from the internal management terminal type 103. When the terminal type information management unit 7 determines the terminal type, the terminal type information management unit 7 transmits the data to the terminal information input unit 5. In step 1296, the terminal information output unit 5 registers the information in the login terminal type management table 34 of the database 24 via the interface 33. The login terminal type management table 34 is composed of a table having the format shown in 91 of FIG. 7, and a data record in which the terminal type 93 and the login terminal identifier 92 are paired is added thereto. At step 1297, the presence server 1 describes the logged-in terminal information in the presence information management table 31 of the database 34, which is a table for managing the login status and presence information of the terminal simultaneously with this processing. The presence information management table 31 is composed of a table of the format indicated by 81 in FIG. 6, and adds a data record in which a terminal address 82 as an identifier of a login terminal and an owner 83 of the terminal are paired. Presence information such as other session information 84 and current state 83 is separately registered by a method different from the login process. In this example, presence information and login information are handled as separate sequences, but it is also possible to perform the same message in one sequence.

Next, User B indicated by 43 logs in the IP telephone terminal 46 in steps 53 and 54. The processing procedure of the presence server 1 generated at this time is the same as in steps 51 and 52. However, the User-Agent of the login message that the IP telephone terminal 46 sends to the SIP server 41 and the presence server 1
The header value is different from the value indicated by 72 in FIG. This is because the video phone terminal 45 and the IP phone terminal 46 have different terminal types. Result Presence server 1 replaces IP phone terminal 46 with video phone terminal 45.
Is recognized as a different terminal type. This is the same even when the User-Agent header is not used for the terminal type information, and different terminals always log in with different terminal type information.

Thereafter, User A indicated by 42 logs in the IP telephone terminal 44. The processing procedure of the presence server 1 that occurs at this time is the same as in steps 51 and 52.
Here, IP phone terminals 44 and 46 have the same terminal type, but 44 is the value of the User-Agent header.
It is assumed that “IPPhone” is described, and 46 is “IPTelephone”.
This is the case when the User-Agent header value is described. For example, there is a possibility that the User-Agent header value assigned in this way may change depending on the vendor that has developed the same IP phone terminal. The presence server 1 maps such terminals with different User-Agent header values in the same terminal type to the same terminal type. This is managed like the two records 1101 and 1102 described in the table 101 of FIG. 8A, and the same internal management terminal type 103 and output form (for SIMPLE) 104 even in different User-Agent headers 102. It is because it maps to. When managing terminal type information in this way, a table that serves as a dictionary for translating the terminal type information notified by each terminal into terminal type information for internal management is prepared. It becomes possible to classify by function or service. Furthermore, there is a possibility that such a terminal type identifier is not added at the time of login depending on the vendor. For such a terminal, a method of mapping to a uniform default terminal type as in record 1103 can be considered. Alternatively, a method of determining the terminal type using a different method may be considered.

Next, UserA shown in 42 transmits an information acquisition request to the presence server 1 in step 36 in order to reserve the current presence information confirmation of UserB shown in 43 and a notification when the presence information changes in the future. When SIP / SIMPLE is used for the interface, a message using the SUBSCRIBE method is transmitted according to the description in Non-Patent Document 3.

The presence server 1 that has received the message performs processing for notifying UserA of the presence information of UserB in step 57 of FIG. Specific processing contents will be described with reference to FIG. When a notification request for presence information is generated in the presence server 1 in step 1301, notification processing is started in step 1302. First, in step 1303, it is checked whether User B permits the presence information disclosure itself to User A. Specifically, the database 24 in FIG.
The permission information described in the permission information management table 35 is retrieved.
A specific configuration of this table is shown in FIG. The table 35 is composed of an access user 302 who requests browsing of presence information, an access target user 303 who discloses the presence information, and permission information 304 describing a presence disclosure policy of the access target user. In the permission information, presence information and permission information for each terminal, that is, setting whether to disclose or not are described. In this example, since UserB browses the presence information of UserA, the search is performed with the search key as column 302 for UserB and column 303 as UserA. Also, the retrieved permission information is temporarily stored in various information temporary tables 25 in FIG.

After confirming the presence information disclosure permission, the presence server 1 uses the terminal information output unit 5 in step 1304 to acquire all the presence information of UserB from the presence information management table 31 of the database 24 of FIG. UserB's presence information is U
It indicates presence information of both the video phone terminal 45 and the IP phone terminal 46 owned by serB. Presence information acquired from the database 24 is held in various information temporary tables 25 on the memory 22 of FIG. 2 for later construction of presence information. Next, presence server 1
In 305, UserB held in the various information temporary table 25 by the notification information selection unit 14 of FIG.
The presence information permitted to be notified to UserA is selected from the presence information. This process is performed using the permission information for UserA of UserB that has been retrieved earlier and temporarily stored in various information temporary tables 25. Presence information for which public permission is not allowed is filtered in this step. The filtered presence information of UserB is transferred to the presence information construction unit 9.

In step 1306, the terminal type information management unit 7 is inquired to acquire terminal type information of each terminal and additional information at the time of constructing presence information. The method of notifying presence information differs for each protocol. Therefore, the method for assigning terminal type information also differs for each protocol. The terminal type information management table 106 shown in FIG. 8 (b) describes the output form of each protocol. Presence information is notified by changing the output form for each protocol. In this example, HTTP output format is described with 105 in addition to SIP / SIMPLE. Next, in step 1307, the presence information construction unit 9 constructs the notification content in the format used when notifying UserA.

In this example, for PIDF (Presence Information Data Fo
The presence information is notified using a format called rmat). In addition, terminal type information is added to the XML (eXchange Markup Language) namespace (Name S
Use pace) function. An example of the constructed presence information is shown in FIG. In FIG. 9, 111 and 112 define the name spaces for IP phones and videophones described in FIG. XML first needs to describe its definition in order to use namespaces. User B shown at 43 in FIG.
And IP phone terminal 46, and the presence information of all of them is notified to User A, so that two name spaces are defined to identify the terminal types of the two terminals. In addition, the abbreviation system for expressing the namespace can be declared in this definition part, and if the namespace is given to the XML text after that, the abbreviation string can be described as a prefix. In this example, the namespace prefix for the video phone terminal is defined as “tvphone”, and the namespace prefix for the IP phone is defined as “phone”.

Presence information described thereafter is given an XML prefix representing the terminal type in front of the presence information name. In FIG. 9, 113 and 114 are the current status (Availability) of the IP phone,
Since it is in-phone information (Session Status), the prefix is “phone”. Further, since 115 and 116 are the current state of the videophone and in-phone information, the prefix is “tvphone”. In this example, terminal information is assigned using the XML namespace, but it is also possible to consider the terminal type as one presence information and describe it in parallel with other presence information.
The presence information created by the above processing is transferred to the presence information transmission / reception unit 11 in FIG. 1 in step 1308 and transmitted to UserA in step 58 in FIG. 4 by a SIP message using the NOTIFY method defined in Non-Patent Document 3. Is done.

After that, it is assumed that the user has logged in at the IP telephone terminal 48 owned by UserC shown at 59 in FIG. Figure 4
The processing procedure from step 59 to step 63 is the same as when UserA logs in, and UserC is viewing the presence information of UserB.
Next, it is assumed that User A shown in 43 of FIG. 3 tries to make a call to User B by using his own IP telephone terminal 44. From the presence information of UserB received at Step 58, UserA can grasp which of the terminals owned by UserB is an IP telephone terminal. Specifically, 117, 118
Confirm the terminal address with the terminal identifier (SIP address) described in, and confirm the terminal type of each terminal with the XML namespace. Therefore, User A can directly ring the telephone bell of the IP telephone terminal 46 owned by User B shown by 43 in FIG. 3, and does not call the video telephone terminal 45 by mistake.

In step 64 of FIG. 4, UserA calls UserB and starts a call. At that time owned by UserB
In step 65, IP telephone terminal 46 notifies presence server 1 that it has entered a call state. Presence server 1 UserA who has reserved notifications because UserB's presence has changed
In step 66 and 67, notification of presence information update is made to UserC.

In step 68, when UserA and UserB are in a call, “in-call information”, which is one of the presence information of IP telephone terminals owned by UserB, becomes “busy”. Even if UserC wants to contact UserB, UserB's IP phone terminal is in a busy state, that is, UserB can see that he is on the phone, so UserC can answer the call until UserB's call ends. If you don't get it, you can understand. If UserB owns a character chat terminal and the “in-call information” of the character chat terminal is busy, UserC is in the state where UserB ’s character chat terminal is busy, that is, UserB is in a chat state I understand. At this time, UserB uses his hand to enter the chat text, but his ears and mouth are available, so it is possible to determine that UserC can contact UserB for urgent contact. In addition, UserA can talk directly to UserB, but UserB's IP phone terminal's "in-call information" can be grasped in the same way as UserC.

Thereafter, when the call between UserA and UserB is terminated in step 69, the IP phone terminal 46 of UserB notifies the presence server 1 of the end of the session in step 70. As a result, the presence server 1 notifies UserA and UserC in steps 1070 and 1071. Notify that the “in-call information” of UserB's IP phone is idle.

At this time, the terminal information is added to the presence information notified to UserA and UserB in the form shown in FIG. By using this information, when displaying session information on the GUIs of the UserA and UserC terminals, it is possible to display what application has established the session from the terminal type. A balloon 228 in FIG. 14 shows what is actually displayed on UserA's GUI. Further, reference numeral 1221 in FIG. 15 is a table image held inside the terminals of UserA and UserC, which describes how each terminal determines the display format of the session information. For example, for terminal A owned by UserB, the value of session information 1224 is “connected” and the terminal type 1225 is an IP phone, so the display format 1226 is “busy”
It is calculated to be. This calculation is terminal dependent and may vary from terminal to terminal. Us
Since erA's terminal has been calculated as “calling”, a display indicating that Mr. B's terminal A is busy is displayed at 228 in FIG.

FIG. 16 is a diagram when the sequence of the portion 1072 in FIG. 4 is realized by another method. Fig. 16 1072
The sequence other than the part is the same as in FIG. In the sequence of FIG. 4, when the session of each terminal is established, the presence server 1 is notified of the fact as presence information in steps 65 and 70 when the session ends. In FIG. 16, this method is different from FIG. In FIG. 16, each terminal does not notify the presence server 1 of the establishment and termination of the session, but the SIP server 41 notifies in steps 1111 and 1112. The SIP server 41 is a server that manages the session information of each terminal, and also grasps the state of establishment and termination of the session of the terminal 2 of User A indicated by 44 and User B indicated by 46. Therefore, it is possible to notify the presence server 1 of the information on session establishment and termination instead of each terminal. By using this method, even if an IP phone that does not have a function of notifying existing session information establishes and terminates a session, the SIP server registers the session state in the presence server 1 on behalf of other users. It becomes possible to grasp the session state of the terminal.

FIG. 17 is a network diagram in the case where the SIP server 321 performs routing based on the terminal type of each terminal. FIG. 18 is a sequence diagram thereof. FIG. 19 is a functional block diagram of a SIP server for performing routing according to the present system, and FIG. 20 is a flowchart of the SIP server. FIG. 21 is a sequence diagram in the case where the routing for grasping the terminal type is realized by a method different from the method of FIG. 18, and FIG. 22 is a block diagram of the SIP server function at that time, FIGS.
FIG. 6 is a flowchart of processing performed by the SIP server at that time. FIG. 25 is a hardware configuration diagram of a SIP server employing this method. The operations of the various functional blocks shown in FIGS. 19 and 22 are housed in the processing module group 1279 of the memory 1272, as in FIGS.
The U1273 reads out and executes the operation procedure. Information necessary when each processing module operates is stored in a location table 1278 and a terminal type table 1280 on the memory 1272. Further, the functional block diagrams of FIGS. 19 and 22 are diagrams showing logical functional configurations realized in software, but each functional block may be configured by hardware.

First, the difference between FIGS. 18 and 21 and FIG. 4 will be described. As shown above, in the sequence of Fig. 4, it is shown as 44.
The terminal (IP phone) owned by UserA obtains the terminal type of the terminal that the other user is logging in from the presence information, and using that information, the terminal 44 itself is shown in 46 among the terminals that UserB logs in to A decision was made to call an IP phone terminal. However, if UserA shown in 44
If the IP telephone terminal does not have the presence acquisition function as shown in 324 of FIG. 17, the terminal type of the other party cannot be specified. Therefore, this method cannot be used as it is. In the method shown in the sequence diagrams of FIGS. 18 and 21, the SIP server 321 performs the confirmation of the terminal type to which User B is logged in, not the IP telephone terminal of User A shown in 324 but a proxy. Even if the IP phone terminal of UserA shown in the result 324 does not have the presence information acquisition function, it is possible to make a call in consideration of the terminal type. The method will be described below with reference to the sequence diagrams of FIGS. Note that the terminals 325 and 326 owned by UserB indicated by 323 in FIG. 17 are described as separate hardware, but as in the case of FIG. 3, the terminals 49 and applications 45 and 46 in FIG. You can take it.

In FIG. 18, first, the IP phone terminal of UserB indicated by 325 in step 1121 logs in to the SIP server 321 and the presence server 1. At this time, in step 1122, the presence server 1 extracts the terminal type information of the terminal 325, and the method is the same as that described above. SIP server 321
19 receives a login message by the login information transmission / reception module 1204 at the time of terminal login, and then stores the login terminal information in the location table 1278 of FIG. 25 by the terminal location management module 1206. Thereafter, the terminal 2 of UserB shown at 326 in step 1123
UserA's IP telephone terminal shown in 324 in 5 performs login, and the processing procedure at that time is step 1121.
, 1122. Next, UserA's IP telephone terminal shown in 324 calls UserB. This time,
Since the terminal 324 does not know the presence of UserB, the call is performed by designating the address of the UserB user itself instead of the terminal address. SIP server 3 that received the call
21 inquires of the presence server 1 in step 1128 about the terminal type of the terminal 324 of the calling user A and the terminal type of the terminal to which the calling user B is logged in. The presence server 1 that has received the inquiry returns the result in step 1123. Specifically, SIP server 32
When 1 receives a SIP message for calling UserB from UserA's IP terminal 324 in step 1127, it receives the SIP message in step 1211 of FIG. 20, and starts processing for message transfer in step 1212. First, in step 1213, the SIP server 321 determines the message type by the message routing module 1203 of FIG. When the message type is determined, it is determined in step 1214 whether the message type requires routing in consideration of the terminal type.

At this time, if it is determined that there is no need to be aware of the terminal type, the process proceeds to step 1220, where normal SIP is performed.
Message routing is performed, the message is transferred in step 1221, and the process ends in step 1224. If it is necessary to be aware of the terminal type, the process proceeds to step 1215. In step 1215, the terminal information inquiry module 1205 of FIG. 19 is used to inquire the presence server 1 of the terminal type of the IP terminal 324 of UserA as the transmission source and the terminal type of the terminal to which UserB is currently logged in. The inquiry method may use a SIP message, or other methods may be used. Thereafter, when the terminal type information is received from the presence server 1 in step 1129 in FIG. 18, the terminal type of the IP terminal 324 of UserA, which is the transmission source, is confirmed in step 1216 in FIG. Confirm the login terminal and its type. In this example, since the terminals to which User B has logged in are the video phone terminal 325 and the IP phone terminal 326, this is confirmed. Next, in step 1218, the message routing module 1203
Checks whether or not UserB as the transmission destination logs in a terminal of the same terminal type as the IP phone terminal 324 of UserA as the transmission source. If UserB as the transmission destination has not logged in a terminal of the same type as the transmission source, the connection will not be established even if the message is transferred to any terminal to which UserB is logged in.

Therefore, the SIP server 321 does not forward the message, creates a 403 response message indicating that connection to the connection destination for UserA, which is the transmission source, cannot be made in Step 1222, returns a response message to UserA in Step 1223, In step 1224, the process ends. In this example, since User B logs in the IP telephone terminal 326, there is a terminal of the same type as the transmission destination. Therefore, the process proceeds to step 1219, and the forwarding address of the call message is set in the IP phone terminal 326 of UserB, and the message is transmitted in step 1221. In step 1224, the process ends.
Result The call message from UserA to UserB is sent from the SIP server 321 to the User at step 1130 in FIG.
The call is transferred to the IP phone terminal 326 of B, and the call is started in step 1131. Thereafter, in step 1132, the call ends.

FIG. 21 is a sequence when the SIP server 321 realizes message routing in consideration of the terminal type other than the method shown in FIG. A different part from FIG. 18 is a method when the SIP server 321 investigates the terminal type of each terminal. In FIG. 18, this is realized by inquiring the presence server 1. However, in FIG. 21, the SIP server 321 has the same terminal type extraction function as the presence server 1, and the terminal type is determined by the SIP server alone when receiving login information. To grasp. Details will be described with reference to FIG.

In FIG. 21, the videophone terminal 325 of UserB logs in to the SIP server 321 and the presence server 1 in step 1141 as in FIG. Next, before transferring the login message to the presence server 1, the SIP server 321 extracts the terminal type of the login terminal in step 1142. Specifically, after receiving the login message at 1231 in FIG. 23, processing for grasping the terminal type is performed at step 1232. When the process starts, in step 1233, the terminal type information extraction module of FIG.
In 1207, terminal type information is extracted from the login message. This processing is exactly the same as the processing when the presence server 1 knows the terminal type, and the login message REGISTER
Extract the part to be used for determining the terminal type from the R message header and parameters. Next, in step 1234, the terminal type is determined. This processing is the same as the presence server 1. The determined terminal information is registered in the terminal type table 1280 in the memory 1272 of FIG. In step 1236, the login information is registered in the location table 1278 on the memory 1280 in FIG. 25, and the processing ends in step 1237. SIP server 321 then steps in FIG.
In 1143, the login information is transferred to the presence server 1.

The subsequent processing of the presence server 1 in step 1144 is the same as described above. Then UserB
IP telephone terminal 326 and UesrA IP telephone terminal 324 log in at steps 1145 and 1149, respectively. The processing procedures of SIP server 321 and presence server 1 at that time are the same as those at step 1141. Thereafter, in step 1153, UserA's IP phone 324 calls UserB. Here, in step 1154, the SIP server 321 determines which terminal is to be called among the terminals to which UserB is logged in. Unlike the sequence procedure in FIG. 18, the SIP server 321 sends the terminal type information to the presence server 1. Instead of making an inquiry, the terminal type information is searched in the terminal type table 1280 on the memory 1272 of FIG. Specifically, the processing is performed according to the flowchart of FIG. The flowchart of FIG. 24 is the same as FIG. 19 except for step 1255. In step 1255, an inquiry is made to the terminal type information management module 1208 in FIG. 22, and the terminal types of the user B terminals 1 and 326 shown in the user A terminals 324 and 325 are investigated. After that, as a result of selecting the destination terminal in the SIP server 321 in step 1154, the SIP server 321 transfers the call message from UserA to UserB to the terminal 2 of UserB shown in 326, that is, the IP telephone terminal in step 1155. . As a result, the call is started in step 1156, and then the call is ended in step 1157.

It is a functional block diagram of a presence server to which a terminal type management system in the present invention is applied. It is a device diagram of a presence server to which a terminal type management system in the present invention is applied. It is a network diagram which shows the connection form using this invention apparatus. It is an operation | movement sequence diagram of the connection form using this invention apparatus. It is the details of the message sent when logging in using SIP. It is a table figure of the presence information which an invention apparatus of this application memorizes. It is a table figure for login terminal classification management which an invention apparatus of this application memorizes. It is a table figure for terminal classification information management which an invention apparatus of this application memorizes. It is an example of a description format of presence information transmitted by the device of the present invention to the outside. It is a network diagram showing the connection form using this invention apparatus. It is a figure for demonstrating the problem which generate | occur | produces when providing the presence information service currently implemented by IM service with the communication network using a SIP server. It is a table figure for permission information which an invention apparatus of this application memorizes. FIG. 6 is a network diagram showing a connection form when a single user logs in twice according to the prior art. It is a display format image figure on a user terminal at the time of combining the terminal classification management function and session information of this invention. It is a table figure when a user terminal memorize | stores the terminal classification information used by this invention. FIG. 4 is a sequence diagram when the SIP server performs proxy start and end in the sequence in FIG. 3. It is a network diagram showing the connection form using this invention apparatus. It is an operation | movement sequence diagram of the connection form using this invention apparatus. It is a functional block diagram of a SIP server to which the terminal type management method in the present invention is applied. It is a process flowchart figure at the time of message routing of the terminal type management in the SIP server of the present invention. It is an operation | movement sequence diagram of the connection form using this invention apparatus. It is a functional block diagram of a SIP server to which the terminal type management method in the present invention is applied. It is a process flowchart figure at the time of terminal classification identification in this invention SIP server. It is a process flowchart figure at the time of message routing in this invention SIP server. It is a device diagram of a SIP server to which the terminal type management system in the present invention is applied. It is a process flowchart figure at the time of terminal type identification in the present invention invention presence notice and presence information notification.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 ... Presence server, 2 ... Permission information control part, 3 ... Permission management part.

Claims (19)

A presence server that can be connected to a connection control server that performs communication connection control between a plurality of terminals, and manages state information of the plurality of terminals,
A line interface;
A control unit that extracts terminal type information of a transmission source terminal of a packet received by the line interface from header information of the received packet;
A storage unit that stores the extracted terminal type information, the counterpart terminal communicating with the transmission source terminal, and connection state information between the transmission source terminal in association with each other;
The presence server, wherein the line interface transmits terminal type information of the transmission source terminal to the partner terminal. The presence server according to claim 1,
The control unit extracts terminal type information of the transmission source terminal connected to the communication connection control server from header information included in a login message received by the line interface,
The presence server, wherein the line interface transmits terminal type information of the transmission source terminal to the partner terminal via the connection control server. The presence server according to claim 1,
A table storing notification availability information of the terminal type information for each communication partner of the transmission source terminal;
A presence server, wherein the terminal type information is transmitted only to a partner terminal to which the terminal type information can be notified. The presence server according to claim 1,
It also has a dictionary table,
The presence server characterized in that the control unit converts the terminal type information extracted from the header information into internal management terminal type information using the dictionary table. The presence server according to claim 1,
The controller is
It is possible to give the terminal type information to each of the plurality of terminals,
A presence server, wherein a method for assigning the terminal type information can be changed for each of the plurality of terminals. The presence server according to claim 5,
The controller is
A presence server that changes a terminal type information output method according to a terminal type information notification protocol used by each of the plurality of terminals. The presence server according to claim 1,
The presence server characterized in that the control unit can freely set a part for extracting the terminal type information in the header information of the packet. A connection control server that performs communication connection control between a plurality of terminals,
A line interface;
A control unit that extracts terminal type information of a transmission source terminal of a packet received by the line interface from header information of the received packet;
A storage unit that stores the extracted terminal type information, the counterpart terminal communicating with the transmission source terminal, and connection state information between the transmission source terminal in association with each other;
The session control server, wherein the line interface transmits the terminal type information of the transmission source terminal to the counterpart terminal. The session control server according to claim 8, wherein
The session control server, wherein the control unit extracts terminal type information of the transmission source terminal from header information included in a login message received by the line interface. The session control server according to claim 8, wherein
It also has a dictionary table,
The session control server, wherein the control unit converts the terminal type information extracted from the header information into internal management terminal type information using the dictionary table. The session control server according to claim 8, wherein
The controller is
It is possible to give the terminal type information to each of the plurality of terminals,
A session control server, wherein a method for assigning the terminal type information is changed for each of the plurality of terminals. The session control server according to claim 9,
The controller is
A session control server, wherein a terminal type information output method is changed according to a terminal type information notification protocol used by each of the plurality of terminals. The session control server according to claim 8, wherein
The session control server, wherein the control unit can freely set a part for extracting the terminal type information in the header information of the packet. The session control server according to claim 8, wherein
A session control server characterized in that messages can be sorted using the terminal type information. The session control server according to claim 14,
A server characterized in that a message distribution policy using the terminal type can be freely changed. The session control server according to claim 14,
A server capable of freely setting a message type as a target of message distribution using the terminal type. The session control server according to claim 14,
When message distribution using the terminal type is not found,
A session control server that returns a message to that effect to the caller. A session control server according to any one of claims 8 to 17,
A session control server using SIP (Session Initiation Protocol) as a session control protocol. A packet relay system that receives a packet transmitted from a terminal or server and relays the packet to another server or terminal,
Means for grasping the terminal type of the terminal or server from the packet transmitted from the terminal or server;
Means for storing the terminal type;
A packet relay system, characterized in that the terminal types are used to connect terminals, servers, or terminals and servers.

Images