JP4582647B2 - Message exchange method for SIP network system - Google Patents

Description

  The present invention relates to a message exchange method in a SIP (Session Initiation Protocol) network system, and in particular, a plurality of nodes including a plurality of SIP servers and gateways are connected in a ring shape, and the same common IP address is assigned to each node. The present invention relates to a method for exchanging messages in a SIP network system.

SIP has become widespread as a de facto standard as a protocol for implementing multimedia services for setting up telephone calls on the IP network and transmitting media such as voice and video over the Internet. According to SIP, in addition to the basic call setting function that general telephone services have, an incoming call charging function, a transfer function, a caller ID notification function, and the like can be realized on an IP network. However, in order for SIP to operate in the full-state method, a dialog for session information and billing information (hereinafter collectively referred to as session information) is generated for each user, and this is registered in SIP, address conversion processing, etc. It is necessary to register with a node (SIP server) that supports call connection. A technique for transmitting and receiving a SIP message via a SIP server is disclosed in Patent Document 1.
JP 2005-198181 A

  When SIP is operated in the full-state method, the user session information increases, so a large load is generated on the SIP server. There is a method of distributing a load to each SIP server by arranging a plurality of SIP servers as a load distribution method of the SIP server. However, in such a load balancing method, it is necessary to set a unique host name and IP address for each SIP server. Therefore, when a SIP server is added, not only the DNS server information needs to be updated, but also when access restrictions are performed on the host name or IP address on the external network, the change is required. It is necessary to change the setting each time.

  In addition, when a user moves (hands off) between SIP servers in an environment with multiple SIP servers, the host name and IP address of the SIP server change, so that notification is sent to the other terminal and other SIP servers on the route. There is a need to. Further, the billing information is collected and held in each server. This may cause an unnecessary message and a security problem due to notification of internal domain information.

  An object of the present invention is to solve the above-described problems of the prior art, and to provide a message exchange method for a SIP network system that can easily distribute the load of a SIP server and can easily realize handoff of a user terminal.

  To achieve the above object, the present invention provides a message exchange in a SIP network system in which a plurality of nodes including a plurality of SIP servers and gateways are connected in a ring shape, and the same common IP address is assigned to each node. In the method, each of the nodes includes a ring side interface (I / F) for transmitting / receiving a message to / from the SIP network and a user side I / F for transmitting / receiving a message to / from the user side network.

  Then, the first SIP server receives the message transmitted from the user terminal from the user-side I / F, and the first SIP server receives the message received from the ring-side I / F on one side. The procedure for forwarding to the adjacent node, the procedure for each node receiving the message from the neighboring node to forward the message from the ring side I / F to the neighboring node on one side, and the destination of the message exists in the ARP cache Means for the gateway to send the message from the user side I / F; a procedure for the gateway to receive a response message to the message from the user side I / F; and the gateway sends the received response message to the ring side I / F. / F forwards to the adjacent node on one side, and each node that receives the response message from the adjacent node A step of transferring over di from the ring-side I / F to one side of the adjacent node, the first 1 SIP server includes a procedure to receive and transmit the response message to the user-side I / F.

  According to the above feature, even when a SIP server is added for the purpose of load distribution, it is not necessary to register an additional server in a DNS server or an external network, so that a load distribution environment can be easily constructed.

  Further, even when the calling terminal moves within the same domain, there is no need to notify the external domain that the SIP server has been changed, and there is no need to change the IP address of the SIP server. Further, billing information can be continuously collected by the same SIP server, and it is not necessary to change the user's default gateway address (Next Hop address) even during handoff between SIP servers.

  DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the best embodiment of the present invention will be described in detail with reference to the drawings. FIG. 1 is a block diagram showing a network configuration of a SIP server system according to the present invention. In the first network (domain1.net), a plurality of SIP servers SV # 1, SV # 2 and SV # 3, and A plurality of nodes including the gateway GW are connected in a ring shape, and the same common IP address “ip1” and the same common host name “ps1” are assigned to all the SIP servers and the gateway GW. The second network (domain2.net) accommodates the SIP server SV # 4. The SIP server SV # 4 is assigned an IP address “ip4” and a host name “ps4”.

  Each SIP server has a session management table that manages each user's session information with a URI unique to each user, and the session information of users E and F is registered in the management table of the SIP server SV # 1. ing. Similarly, session information of user A is registered in the management table of SIP server SV # 2, and session information of users C and D is registered in the management table of IP server SV # 3. All nodes include a ring-side interface that transmits and receives messages to and from the SIP network, and a user-side I / F that transmits and receives messages to and from the user-side network.

  Next, referring to the flowcharts of FIGS. 2, 3 and 4 and the block diagram of FIG. 6, when the user A in the first domain (domain1.net) makes a call to the user B in the external second domain (domain2.net) The call connection procedure will be described.

  As shown in FIG. 6, the user A sends an IP address “ip1” whose destination (target) IP address is common to each SIP server, and the source IP address is his / her own IP address “ipA” from the SIP phone # 1. ”, The type is SIP-INVITE (call), the sender address (From header) is its own URI“ UserA@domain1.net ”, the callee address (To header) is the URI“ UserB@domain2.net ”of user B Yes, an Ethernet (registered trademark) frame in which the host name “hostA@domain1.net” is registered in the Via header is transmitted.

  When the SIP server SV # 2 receives the frame in step S1 in FIG. 2, it is determined in step S2 whether the receiving interface is the user side or the ring side based on the sender address. Here, since it is determined as the user side, the process proceeds to step S3, and a packet is captured from the received frame. In step S4, the destination is determined on the basis of the destination IP address. Here, since it is determined to be “addressed to itself”, the process proceeds to step S5. In step S5, the received packet is transferred from the ring side interface to the adjacent server on one side, and then the process proceeds to step S18.

  In step S18, the received packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20. In step S20, it is determined whether the received packet is a request or a response. Here, since the packet is determined to be a request, the process proceeds to step S50 in FIG.

  In step S50, it is determined whether or not the caller address is the own domain. Here, since it is determined to be the own domain, the process proceeds to step S51. In step S51, it is determined whether or not the sender address URI exists in the management table. Since it is determined that the URI exists here, the process proceeds to step S52. In step S52, the host name “ps1.domain1.net” is added to the Vai header of the received packet. In step S53, it is determined whether or not the address of the recipient is in the own domain. Here, since it is determined that the address is not in the own domain, the process proceeds to step S56. In step S56, the destination IP address is changed to the IP address “ip4” of the SIP server SV # 4, and the transmission source IP address is changed to the common IP address “ip1”. In step S57, the packet with the changed IP address is transferred from the ring side interface to the adjacent node on one side.

  When the SIP server SV # 3 receives this packet in step S1 of FIG. 2, in step S2, since the reception interface is determined to be the ring side, the process proceeds to step S10. In step S10, it is determined whether or not the transfer count of the received packet has reached a predetermined maximum transfer count based on whether or not the remaining transfer count Tn of the received packet is “0”. In the present embodiment, the maximum number of transfers is set to four, and if the remaining number Tn is “0”, it is determined that the maximum number of transfers has been reached, the process proceeds to step S21, and the received packet is discarded. If the remaining number Tn is other than “0”, it is determined that the maximum number of transfers has not been reached, and the process proceeds to step S11, where the remaining number Tn is decremented by “1”.

  In step S12, the received packet is transferred from the ring side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13. In step S14, the destination IP address of the received packet is referred to, and here it is determined that it is neither “addressed to me” nor “Any”, so the process proceeds to step S15. In step S15, it is determined whether or not the destination IP address is present in its own ARP cache entry. Here, it is determined that the destination IP address is not registered, and thus the process proceeds to step S17 and the packet is discarded. When the gateway GW receives the frame transferred by the SIP server SV # 3 in step S12, the destination IP address “ip4” exists in the ARP cache entry. In other words, the SIP server SV # 4 is installed on the user side interface. Since it exists, this is transmitted from the user side interface to the SIP server SV # 4.

  As shown in FIG. 6, the SIP server SV # 4 changes the destination IP address of the received packet to the IP address “ipB” of the SIP phone # 2, and also changes the source IP address to its own IP address “ip4”. This is transmitted to SIP phone # 2. Furthermore, when the SIP server SV # 4 receives the 200OK response from the SIP phone # 2, the gateway IP address is changed to the common IP address “ip1” and the source IP address is changed to its own IP address “ip4”. Send to GW. The gateway GW of domain1.net transfers the received response message to the adjacent server on one side.

  When the SIP server SV # 1 receives the frame transferred from the gateway GW at step S1 in FIG. 2, the reception interface is determined to be the ring side at step S2, and the process proceeds to step S12 via steps S10 and S11. In step S12, the received packet is transferred from the ring side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13.

  In step S14, the destination IP address is referred to, and here it is determined that it is “addressed to itself”. In step S18, the packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20. In step S20, it is determined whether the received packet is a request or a response. Here, since it is determined that the received packet is a response, the process proceeds to step S30 in FIG.

  In step S30, it is determined whether or not the recipient address is in the own domain. Here, since it is determined that the address is not in the own domain, the process proceeds to step S44. In step S44, it is determined whether or not the sender address is the own domain. Here, since it is determined that the sender address is the own domain, the process proceeds to step S45. In step S45, it is determined whether the URI of the sender address exists in the management list. Since it is determined that the URI does not exist here, the process proceeds to step S43 and the packet is discarded.

  When the SIP server SV # 2 receives the packet forwarded to the ring side in step S12 by the SIP server SV # 1 in step S1, the SIP server SV # 2 proceeds to step S45 through a procedure similar to that in the SIP server SV # 1. In step S45, since it is determined that the URI of the sender address exists in the management table, the process proceeds to step S35, and its own URI “ps1.domaini.net” is deleted from the Via head. In step S36, the destination IP address of the received packet is replaced with the IP address “ipA” of SIP phone # 1 corresponding to the URI of the caller address, and the source IP address is the common IP address assigned to itself. It will be replaced with “ip1”. In step S37, it is determined whether or not the destination IP address exists in the ARP cache entry. Since it is determined here that the destination IP address exists, the process proceeds to step S39. In step S39, the packet whose IP address has been changed is transmitted from the user side interface to SIP phone # 1.

  Next, the operation at the time of incoming from the external domain will be described with reference to the block diagram of FIG. 7 and each flowchart. Here, transmission from User B's SIP phone # 2 to User A's SIP phone # 1 under the SIP server SV # 2 will be described as an example.

  As shown in FIG. 7, from the SIP phone # 2, the user B has a destination (target) IP address of the IP address “ip4” of the SIP server # 4 and a source (source) IP address of its own IP address “ipB” ”, The type is SIP-INVITE (call), the sender address (From header) is its own URI“ UserB@domain2.net ”, the recipient address (To header) is the URI“ UserA@domain1.net ”of user A Yes, an Ethernet (registered trademark) frame in which the host name “hostB@domain2.net” is registered in the Via header is transmitted.

  In SIP server SV # 4, the destination IP address of the received packet is changed to IP address “ip1” common to each SIP server of domainnet1.net, the source IP address is changed to its own IP address “ip4”, and Via The host name “ps4.domain2.net” is added to the header.

  When the gate server GW receives the Ethernet (registered trademark) frame from the SIP server SV # 4, the gate server GW transfers it to the adjacent server on one side from the ring side interface. When the SIP server SV # 1 receives this packet at step S1 in FIG. 2, the reception interface is determined to be the ring side at step S2, and the process proceeds to step S12 via steps S10 and S11. In step S12, the received packet is transferred from the ring-side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13.

  In step S14, the destination IP address of the received packet is referred to, and here it is determined to be “addressed to itself”, so the process proceeds to step S20 via steps S18 and S19. In step S20, it is determined whether the received packet is a request or a response. Since it is determined to be a request here, the process proceeds to step S50 in FIG.

  In step S50, it is determined whether or not the sender address registered in the From header of the received packet is in the own domain. Here, since it is determined that the sender is not in the own domain, the process proceeds to step S66. In step S66, it is determined whether or not the callee address is in the own domain. Here, since it is determined in the own domain, the process proceeds to step S67. In step S67, it is determined whether or not the URI of the called party address exists in the management table. Since it is determined that it does not exist here, the process proceeds to step S64 and the packet is discarded.

  When the SIP server SV # 2 receives the frame transferred to the ring side by the SIP server SV # 1 in step S12 in step S1, the SIP server SV # 2 proceeds to step S67 through a procedure similar to that in the SIP server SV # 1. In step S67, since it is determined that the URI of the recipient address exists in the management table, the process proceeds to step S55, and its own host name is added to the Via header.

  Thereafter, the process proceeds to step S36 in FIG. 4, where the destination IP address of the received packet is replaced with the IP address “ipA” of SIP phone # 1 corresponding to the URI of the callee address, and the source IP address is To the common IP address “ip1” assigned to. In step S37, it is determined whether or not the destination IP address exists in the ARP cache entry. Since it is determined here that the destination IP address exists, the process proceeds to step S39. In step S39, the packet whose IP address has been changed is transmitted from the user side interface to SIP phone # 1.

  When the SIP server SV # 2 receives the response packet from the SIP phone # 1 in step S1 in FIG. 2, the process proceeds to step S20 via steps S2, S3, S4, S5, S18, and S19 as described above. In step S20, since the received packet is determined to be a response, the process proceeds to step S30 in FIG.

  In step S30, since the callee address is determined to be the own domain, the process proceeds to step S31. In step S31, it is determined whether or not the URI of the called party address exists in the management table. Since it is determined here to exist, the process proceeds to step S32, and its own domain “ps1.domain1.net” is deleted from the Via header. Is done. In step S33, it is determined whether or not the caller address is in the own domain. Here, since it is determined that the sender address is not in the own domain, the process proceeds to step S46. In step S46, the destination IP address is changed to the IP address “ip4” of the SIP server SV # 4, and the transmission source IP address is changed to the common IP address “ip1”. In step S47, the packet whose IP address has been changed is transferred from the ring side interface to the adjacent node on one side.

  When the SIP server SV # 3 receives the packet forwarded to the ring side in step S47 by the SIP server SV # 2 in step S1, the reception interface is determined to be the ring side in step S2, so that the steps go through steps S10 and S11. Proceed to step S12. In step S12, the received packet is transferred from the ring side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13.

  In step S14, since it is determined that the received packet is “addressed to itself”, the process proceeds to step S18, where the received packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20, and it is determined whether the received packet is a request or a response. Since the response is determined here, the process proceeds to step S30 in FIG.

  In step S30, since the callee address is determined to be the own domain, the process proceeds to step S31. Here, since it is determined that the URI of the callee address does not exist in the management table, the process proceeds to step S40. In step S40, it is determined whether or not the sender address is in the own domain. Here, since it is determined that the sender address is not in the own domain, the process proceeds to step S43 and the packet is discarded.

  When the gateway GW receives the packet from the adjacent SIP server SV # 3, since the destination IP address “ip4” exists in the ARP cache entry, the gateway GW transfers the packet to the SIP server SV # 4. In the SIP server SV # 4, the destination IP address of the received packet is changed to the IP address “ipB” of the user B, and the source IP address is changed to the own IP address “ip4”. The packet whose IP address has been changed is transferred to the user B from the user side interface.

  Next, referring to the block diagram of FIG. 8 and each flowchart, the user A of the first domain (domain1.net) moves to another SIP server in the same domain and moves to the second domain (domain2.net). A call connection procedure when making a call to user B will be described. Here, a case will be described as an example where user A, whose session information is registered in SIP server SV # 2, transmits via SIP server SV # 3.

  As shown in FIG. 8, the user A sends the IP address “ip1” common to each SIP server from the SIP phone # 1, and the IP address “ipA” as the source IP address of the user A. ”, The type is SIP-INVITE (call), the sender address (From header) is its own URI“ UserA@domain1.net ”, the callee address (To header) is the URI“ UserB@domain2.net ”of user B Yes, send a frame with its host name “hostA@domain1.net” registered in the Via header.

  When the SIP server SV # 3 receives the frame in step S1 of FIG. 2, the received packet is transferred from the ring side interface to the adjacent server on the one side in step S5, and then proceeds to step S18. . In step S18, the received packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20. In step S20, it is determined whether the received packet is a request or a response. Here, since the packet is determined to be a request, the process proceeds to step S50 in FIG.

  In step S50, it is determined whether or not the caller address is the own domain. Here, since it is determined to be the own domain, the process proceeds to step S51. In step S51, it is determined whether or not the URI of the sender address exists in the management table. Here, since it is determined that the URI does not exist, the process proceeds to step S61. In step S61, since it is determined that the callee address is other than the own domain, the process proceeds to step S64 and the received packet is discarded. When the gateway server GW receives the packet transferred by the SIP server SV # 3 in step S5, the gateway server GW does not have the destination IP address in its own ARP cache entry, and transfers it directly to the adjacent server on one side.

  When the SIP server SV # 1 receives the frame transferred from the gateway GW at step S1 in FIG. 2, the process proceeds to step S12 via steps S2, S10, and S11. In step S12, the received packet is transferred from the ring side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13. In step S14, since it is determined that the destination IP address is “addressed to me”, the process proceeds to step S18. In step S18, the packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20. In step S20, since the received packet is determined to be a request, the process proceeds to step S50 in FIG. Thereafter, as in the case of the SIP server SV # 3, the process proceeds to step S64 and the received packet is discarded.

  When the SIP server SV # 2 receives the packet transferred by the SIP server SV # 1 in step S12 in step S1 in FIG. 2, the SIP server SV # 2 proceeds to step S51 as in the case of the SIP server SV # 1. In step S51, it is determined whether or not the URI of the sender address exists in the management table. Here, since it is determined that the URI exists, the process proceeds to step S52. In step S52, the host name “ps1.domain1.net” is added to the Vai header of the received packet.

  In step S53, it is determined whether or not the address of the recipient is in the own domain. Here, since it is determined that the address is not in the own domain, the process proceeds to step S56. In step S56, the destination IP address is changed to the IP address “ip4” of the SIP server SV # 4 based on the URI of the callee address, and the source IP address is changed to the common IP address “ip1”. In step S57, the packet with the changed IP address is transferred from the ring side interface to the adjacent node on one side. Thereafter, the packet is transferred from the gateway GW to the user B as in the embodiment described with reference to FIG.

  A packet returned from the SIP server SV # 4 in the external domain is transferred to the SIP server SV # 2 via the gateway GW and the SIP server SV # 1 as described above. When the SIP server SV # 2 receives the packet in step S1 in FIG. 2, the process proceeds to step S30 in FIG. 4 through steps S2, S10, S14, and S20.

  In step S30, since it is determined that the recipient address is other than the own domain, the process proceeds to step S44. In step S44, since the caller address is determined to be its own domain, the process proceeds to step S45. In step S45, since it is determined that the URI of the sender address exists in the management table, the process proceeds to step S35. In step S35, its own URI “ps1.domaini.net” is deleted from the Via head.

  In step S36, the destination IP address of the received packet is changed to the IP address “ipA” of SIP phone # 1 corresponding to the URI of the sender address, and the source IP address is changed to the common IP address “ip1”. In step S37, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that the destination IP address does not exist, the process proceeds to step S38. In step S38, the packet whose IP address has been changed is transferred from the ring side interface to the adjacent server on one side.

  When the SIP server SV # 3 receives this packet in step S1, it proceeds to step S14 as in the case of the SIP server SV # 2. In step S14, since the destination is neither self addressed nor Any, the process proceeds to step S15. In step S15, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that the destination IP address exists, the process proceeds to step S16, and the received packet is transmitted from the user side interface to SIP phone # 1.

  Next, referring to the block diagram of FIG. 9, the user A in the first domain (domain1.net) moves to another SIP server in the same domain and the user B in the second domain (domain2.net) A call connection procedure when receiving an incoming call will be described. Here, a case where user A, whose session information is registered in SIP server SV # 2, receives an incoming call via SIP server SV # 3 will be described as an example. Note that the procedure for the packet transmitted from the user B to reach the SIP server SV # 2 via the gateway GW and the SIP server SV # 1 is the same as that in the embodiment described with reference to FIG.

  When the SIP server SV # 2 receives the frame transferred to the ring side in step S12 by the SIP server SV # 1, in step S1, the SIP server SV # 2 proceeds to step S67 in FIG. 3 through a procedure similar to that in the SIP server SV # 1. In step S67, since it is determined that the URI of the recipient address exists in the management table, the process proceeds to step S55, and its own host name is added to the Via header.

  Thereafter, the process proceeds to step S36 in FIG. 4, where the destination IP address of the received packet is replaced with the IP address “ipA” of SIP phone # 1 corresponding to the URI of the callee address, and the source IP address is To the common IP address “ip1” assigned to. In step S37, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that SIP phone # 1 has already moved and does not exist, the process proceeds to step S38. In step S38, the packet whose IP address has been changed is transferred from the ring side interface to the adjacent server on one side.

  When the SIP server SV # 3 receives this packet in step S1, it proceeds to step S14 as in the case of the SIP server SV # 2. In step S14, since the destination is neither self nor Any, the process proceeds to step S15. In step S15, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that the destination IP address exists, the process proceeds to step S16, and the received packet is transmitted from the user side interface to SIP phone # 1.

  When SIP server SV # 3 receives the response packet from SIP phone # 1 in step S1 of FIG. 2, it proceeds to step S20 via steps S2, S3, S4, S5, S18, and S19 as described above. In step S20, since the received packet is determined to be a response, the process proceeds to step S30 in FIG.

  In step S30, since the callee address is determined to be the own domain, the process proceeds to step S31. In step S31, it is determined whether or not the URI of the callee address exists in the management table, and since it is determined that it does not exist here, the process proceeds to step S40. In step S40, since it is determined that the sender address is other than the own domain, the process proceeds to step S43, and the packet is discarded.

  When the gateway server GW receives the packet transferred by the SIP server SV # 3 in step S5, the gateway server GW does not have the destination IP address “ip1” in its own ARP cache entry, and transfers it directly to the adjacent server on one side.

  When the SIP server SV # 1 receives the frame transferred from the gateway GW at step S1 in FIG. 2, the process proceeds to step S12 via steps S2, S10, and S11. In step S12, the received packet is transferred from the ring side interface to the adjacent server on one side. In parallel with this, the received packet is captured in step S13. In step S14, since it is determined that the destination IP address is “addressed to me”, the process proceeds to step S18.

  In step S18, the packet is received from the SIP application port. In step S19, the method type is determined. Here, since it is determined that the communication is between the user and the user, the process proceeds to step S20. In step S20, since the received packet is determined to be a response, the process proceeds to step S30 in FIG. 4, and then proceeds to step S43 via steps S44 and S45, and the packet is discarded.

  When the SIP server SV # 2 receives the packet transferred by the SIP server SV # 1 in step S12 in step S1 in FIG. 2, the SIP server SV # 2 proceeds to step S45 as in the case of the SIP server SV # 1. In step S45, since it is determined that the URI of the sender address exists in its own management table, the process proceeds to step S35. In step S35, its own URI “ps1.domaini.net” is deleted from the Via head.

  In step S36, the destination IP address of the received packet is changed to the IP address “ip4” of the SIP server SV # 4 corresponding to the URI of the sender address, and the source IP address is changed to the common IP address “ip1”. . In step S37, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that the destination IP address does not exist, the process proceeds to step S38. In step S38, the packet whose IP address has been changed is transferred from the ring side interface to the adjacent server on one side.

  Thereafter, in the same manner as described above, the packet is returned to the SIP phone # 2 of the user B via the SIP server SV # 3, the gateway GW, and the SIP server # 4 of domain2.net.

  Next, a message exchange procedure between users / users in the same domain will be described with reference to the block diagram of FIG. 10 and each flowchart.

  User A starts from SIP phone # 1, and the destination IP address is the common IP address “ip1” for each SIP server, the source IP address is its own IP address “ipA”, the type is SIP-INVITE, the sender address (From header ) Is its own URI `` UserA@domain1.net '', the recipient address (To header) is the URI of User B `` UserB@domain1.net '', and its host name `` hostA@domain1.net '' is in the Via header Send the registered frame.

  When the SIP server SV # 2 receives the frame in step S1 of FIG. 2, in step S2, the receiving interface is determined to be the user side based on the sender address, and thus the process proceeds to step S3. Packets are captured. In step S4, since it is determined that the destination of the packet is “addressed to itself”, the packet is transferred to the adjacent node on one side in step S5, and then the process proceeds to step S18. In step S18, the received packet is received by the SIP application port, and the process proceeds to step S20 via step S19. In step S20, since the message is determined to be a request, the process proceeds to step S50 in FIG.

  In step S50, since the sender address is determined as the own domain, the process proceeds to step S51. Here, since it is determined that the URI of the sender address exists in the management table, the process proceeds to step S52. In step S52, the host name “ps1.domain1.net” is added to the Vai header of the received frame. In step S53, since it is determined that the destination address is the own domain, the process proceeds to step S54. Here, since it is determined that the URI of the callee address does not exist in the management table, the process proceeds to step S58. In step S58, the destination IP address is changed to “Any”, and the transmission source IP address is changed to the common IP address “ip1”. In step S59, the readdressed packet is transferred from the ring side interface to the adjacent node on one side.

  When the SIP server SV # 3 receives the packet transferred by the SIP server SV # 2 to the ring side in step S59 in step S1 in FIG. 2, in step S2, the reception interface is determined to be the ring side. The process proceeds to step S12 via S11, and the received packet is transferred from the ring side interface to the adjacent node. In parallel with this, the received packet is captured in step S13, and the destination IP address is identified in step S14. Here, since the destination is determined to be “Any”, the process proceeds to step S50 in FIG. 3 through steps S18, S19, and S20.

  In step S50, since the sender address is determined as the own domain, the process proceeds to step S51. Here, since it is determined that the URI of the sender address does not exist in the management table, the process proceeds to step S61. In step S61, since the callee address is determined to be the own domain, the process proceeds to step S62. Here, since it is determined that the URI of the callee address does not exist in the management table, the process proceeds to step S64 and the received packet is discarded. The

  When the SIP server SV # 3 receives the packet forwarded to the ring side in step S12 by the SIP server SV # 3 in step S1, the SIP server SV # 4 proceeds to step S62 as in the case of the SIP server SV # 3. In step S62, it is determined that the URI of the callee address exists in the management table, so the process proceeds to step S63. In step S63, it is determined whether or not the Via header of the own host name exists. Since it is determined here, the host name is added to the Via header in step S55, and then the process proceeds to step S36 in FIG. The destination IP address is changed to the IP address “ipB” of SIP phone # 2 corresponding to the URI of the callee address. In step S37, since it is determined that the destination IP address exists in the ARP cache entry, the process proceeds to step S39, and the address-replaced packet is transmitted from the user side interface to SIP phone # 2.

  When SIP phone # 2 transmits a response to the request message and SIP server SV # 4 receives this message in step S1, step S20 goes through steps S1, S2, S3, S4, S5, S18, and S19. Proceed to In step S20, since the message type is determined to be a response, the process proceeds to step S30 in FIG.

  In step S30, it is determined that the callee address is the own domain. In step S31, it is determined that the URI of the callee address exists in the management table, so the process proceeds to step S32. In step S32, only one host name “ps1.domain1.net” is deleted from the Via header. In step S33, it is determined that the caller address is the own domain. In step S34, it is determined that the URI of the caller address does not exist in the management table, so the process proceeds to step S48. In step S48, the destination IP address is changed from “ip1” to “Any”, and the transmission source IP address is changed from “ipB” to “ip1”. In step S49, the address-replaced frame is transferred from the ring side interface to the adjacent server on one side.

  When the SIP server SV # 4 receives the packet transferred to the ring side in step S49 by the SIP server SV # 4 in step S1, the SIP server # 5 proceeds to step S30 in FIG. 4 via steps S2, S10, S12, S14, and S20. . In step S30, it is determined that the callee address is the own domain. In step S31, it is determined that the URI of the callee address does not exist in the management table, so the process proceeds to step S40. In step S40, it is determined that the caller address is the own domain. In step S41, it is determined that the URI of the caller address does not exist in the management table, so the process proceeds to step S43 and the received packet is discarded. Each procedure described above is executed in the same way in the gateway GW and the SIP server SV # 1.

  When the SIP server SV # 2 receives the packet forwarded to the ring side in step S12 by the SIP server SV # 1 in step S1, the SIP server SV # 2 proceeds to step S41 in the same procedure as the SIP server SV # 5. In step S41, it is determined whether the URI of the sender address exists in the management table. Since it is determined that it exists here, the process proceeds to step S42. In step S42, since it is determined that the host name is registered in the Via header, the process proceeds to step S39 via steps S35, S36, and S37. In step S39, the address-changed frame is transmitted from the user side interface to SIP phone # 1.

  11, 12, and 13 are diagrams showing another example of a procedure for exchanging messages between users / users in the same domain. FIG. 11 shows that the receiving terminal of user B has its own session information This shows the procedure for moving to a non-existing SIP server # 5 and receiving a call. FIG. 12 shows a procedure when the transmission terminal of the user A moves under the SIP server # 3 in which his / her session information does not exist and transmits. FIG. 13 shows a procedure when the transmitting terminal of user A and the receiving terminal of user B both make and receive calls by moving under the SIP servers # 3 and # 5 that do not have their own session information.

  Since the operation of each SIP server is apparent with reference to the flowcharts of FIGS. 2, 3, 4 and 5, only the contents of the headers of frames and packets transmitted and received between servers and between server / user terminals are shown here. The description of the operation is omitted.

  Next, the location registration procedure between the user / server in the same domain will be described with reference to the block diagram of FIG. 14 and each flowchart.

  User A uses SIP phone # 1, the destination IP address is “ip1”, the IP address common to each SIP server, the source IP address is “ipA”, the type is REGISTER (location registration request), and the sender address (From header) and recipient address (To header) are both their own URI “UserA@domain1.net”, and frames with their host name “hostA@domain1.net” registered in the Via header To do.

  When the SIP server SV # 2 receives the frame in step S1 of FIG. 2, in step S2, the receiving interface is determined to be the user side based on the sender address, and thus the process proceeds to step S3. Packets are captured. In step S4, since it is determined that the destination of the packet is “addressed to itself”, the packet is transferred to the adjacent node on one side in step S5, and then the process proceeds to step S18. In step S18, the received packet is received at the SIP application port. In step S19, the Method type of the message is determined. Here, since it is determined that the communication is between the user and the server, the process proceeds to step S81 in FIG.

  In step S81, since the message is determined to be a request, the process proceeds to step S82. Here, since the callee address is determined to be the own domain, the process proceeds to step S83. In step S83, it is determined whether or not the URI of the callee address exists in the management table. Since it is determined here to exist, the process proceeds to step S84, a predetermined location registration process is executed and a response message is generated. The In step S85, the destination IP address is changed to the IP address “ipA” of SIP phone # 1, and the transmission source IP address is changed to the common IP address “ip1”.

  In step S86, it is determined whether or not the destination IP address exists in the ARP cache entry. Here, since it is determined that the destination IP address exists, the process proceeds to step S87. In step S87, the response message with the changed address is transmitted from the user side interface to SIP phone # 1.

  If the session management information of user A exists in the SIP server SV # 3 instead of the SIP server SV # 2, the SIP server SV # 2 proceeds from step S83 to S92, and the packet is discarded. The SIP server SV # 3 receives the packet transferred from the SIP server SV # 2 and proceeds to step S83, and further proceeds to step S86. Since it is determined that the destination IP address does not exist in the ARP cache entry, In step S88, the packet is transferred from the ring side interface to the adjacent node on one side. The packet is transferred to SIP server SV # 2 via SIP servers SV # 4 and # 5, gateway GW and SIP server SV # 1, and is transmitted from SIP server SV # 2 to SIP phone # 1.

  15, 16, and 17 are diagrams illustrating other examples of registration and notification procedures between users / servers in the same domain. FIG. 15 illustrates the session information of the user A's terminal. Shows the procedure for moving to a subordinate of SIP server # 4 that does not exist and performing location registration. FIG. 16 shows a procedure when the terminal of the user A receives a notification under the SIP server # 2 in which his / her session information exists. FIG. 17 shows a procedure when the terminal of user A moves under the SIP server # 4 for which his / her session information does not exist and receives a notification.

  Since the operation of each server is apparent with reference to the flowcharts of FIGS. 2, 3, 4 and 5, only the contents of the headers of frames and packets transmitted and received between servers and between server / user terminals are shown here. Explanation of the operation is omitted.

1 is a block diagram showing a network configuration of a SIP server system according to the present invention. It is the flowchart (the 1) which showed the control procedure of the SIP server system. It is the flowchart (the 2) which showed the control procedure of the SIP server system. It is the flowchart (the 3) which showed the control procedure of the SIP server system. It is the flowchart (the 4) which showed the control procedure of the SIP server system. It is the block diagram which showed typically the transfer path | route of the message at the time of a user transmitting to a foreign domain from the subordinate of the SIP server which manages his session information. It is the block diagram which showed typically the transfer path | route of the message when a user receives from an external domain under the control of the SIP server which manages own session information. It is the block diagram which showed typically the transfer path | route of the message when a user transmits to a foreign domain from subordinates other than the SIP server which manages own session information. It is the block diagram which showed typically the transfer path | route of the message when a user receives from an external domain under control other than the SIP server which manages own session information. It is the block diagram which showed typically the message exchange procedure (Both transmission / reception terminals are fixed) between the users / users in the same domain. It is the block diagram which showed typically the message exchange procedure (a receiving terminal moves) between the users / users in the same domain. It is the block diagram which showed typically the message exchange procedure (a transmission terminal moves) between the users / users in the same domain. It is the block diagram which showed typically the message exchange procedure (Both transmission / reception terminals move) between the users / users in the same domain. It is the block diagram which showed typically the registration procedure (registration in a movement origin) between the users / servers in the same domain. It is the block diagram which showed typically the registration procedure (registration in a movement destination) between the user / server in the same domain. It is the block diagram which showed typically the notification procedure (notification in a movement origin) between the user / server in the same domain. It is the block diagram which showed typically the notification procedure (notification in a movement destination) between the user / server in the same domain.

Claims (8)

In a SIP network system message exchange method in which a plurality of nodes including a plurality of SIP servers and gateways are connected in a ring shape, and a common IP address is assigned to each node.
Each of the nodes
A management table for managing user terminal session information;
A ring side interface (I / F) for sending and receiving messages to and from the SIP network;
A user-side I / F that transmits and receives messages to and from the user-side network;
First , the user terminal registers its own IP address as the source IP address, the common IP address as the destination IP address, the URI of the user terminal as the caller address, and the URI of the external domain as the callee address A procedure for sending a request message;
A procedure in which a first SIP server receives the first request message from a user-side I / F;
The first SIP server forwards the received first request message from the ring side I / F to an adjacent node on one side;
Each node receiving the first request message from an adjacent node, a procedure for transferring the first request message from the ring side I / F to one side of the adjacent node,
When the second SIP server that manages the session information of the user terminal transfers the first request message to an adjacent node, it changes the source IP address of the first request message to a common IP address, Procedure to change the IP address to the IP address of the external domain based on the callee address,
Gateway to the destination of the first request message is present in the ARP cache, and procedures for transmitting the first request message from the user I / F,
The gateway comprises a step of receiving a first response message to the first request message from the user I / F,
The gateway forwards the received first response message from the ring side I / F to an adjacent node on one side;
Each node receiving the first response message from the adjacent node, a procedure for transferring the first response message from the ring side I / F to one side of the adjacent node,
A procedure in which the second SIP server replaces the destination IP address of the first response message received from the adjacent node with the IP address of the user terminal, and replaces the source address with the common IP address;
A message exchange method for a SIP network system, comprising: a step in which the first SIP server receives the first response message to which the address has been changed and transmits the response message to a user-side I / F. Second, the gateway has the external domain IP address registered as the source IP address, the common IP address registered as the destination IP address, the URI of the external domain registered as the caller address, and the URI of the user terminal registered as the callee address . Receiving the request message from the user side I / F,
The gateway forwards the received second request message from the ring side I / F to an adjacent node on one side;
Each node receiving the second request message from the adjacent node, a procedure for transferring the second request message from the ring side I / F to one side of the adjacent node,
A procedure in which the second SIP server replaces the source IP address of the second request message received from an adjacent node with a common IP address, and replaces the destination IP address with the IP address of the first user terminal;
A procedure in which a first SIP server in which the destination of the second request message exists in an ARP cache receives the second request message and transmits it to the user-side I / F;
And procedures for the user terminal returns a second response message to the second request message,
A procedure in which the first SIP server receives the second response message from a user-side I / F;
The first SIP server forwards the received second response message from the ring side I / F to an adjacent node on one side;
Each node that receives the second response message from the adjacent node forwards the second response message from the ring side I / F to the adjacent server on one side;
A procedure in which the second SIP server replaces a source address of the second response message received from an adjacent node with a common IP address and a destination IP address with an IP address of an external domain;
The gateway is a message exchange method for SIP network system according to claim 1, characterized in that it comprises a procedure for transmitting the received from the neighbor node a second response message from the user I / F. The third request in which the user terminal registers its own IP address as the source IP address, the common IP address as the destination IP address, the URI of the user terminal as the caller address, and the URI of the internal domain as the callee address Instructions for sending messages,
A procedure in which the first SIP server receives the third request message from the user side I / F;
A procedure in which the first SIP server transfers the received third request message from the ring side I / F to an adjacent node on one side;
Each node receiving the third request message from the adjacent node, a procedure for transferring the third request message from the ring side I / F to one side of the adjacent node,
When the second SIP server that manages the session information of the user terminal transfers the third request message to an adjacent node, the source IP address of the third request message is changed to a common IP address, and the destination The procedure to change the IP address to Any,
The third SIP server to which the destination of the third request message is present in the ARP cache, and procedures for transmitting the third request message from the user I / F,
A step of the third SIP server receives a third response message to the third request message from the user I / F,
A procedure in which the third SIP server changes the destination IP address of the third response message to Any, changes the source IP address to a common IP address, and transfers the same from the ring side I / F to an adjacent node on one side; ,
Each node receiving the third response message from the adjacent node, a procedure for transferring the third response message from the ring side I / F to one side of the adjacent node,
A procedure in which the second SIP server replaces the destination IP address of the third response message received from the adjacent node with the IP address of the user terminal, and replaces the source address with the common IP address;
3. The SIP network system message according to claim 1, further comprising a procedure in which the first SIP server transmits the third response message received from an adjacent node from a user-side I / F. 4. method of exchange. A procedure in which the user terminal transmits a registration message in which the own IP address is registered in the source IP address, the common IP address is registered in the destination IP address, and the URI of the user terminal is registered in the caller address and the callee address;
A procedure in which the first SIP server receives the registration message from the user-side I / F;
The first SIP server forwards the received registration message from the ring side I / F to an adjacent node on one side;
Each node that receives the registration message from an adjacent node forwards the registration message from the ring side I / F to the adjacent node on one side;
A second SIP server that manages session information of the user terminal processes the registration message;
When the second SIP server transfers a fourth response message to the registration message to an adjacent node, the source IP address of the fourth response message is replaced with a common IP address, and the destination IP address is changed to the user terminal. The procedure to change to the IP address of
The SIP network according to any one of claims 1 to 3, further comprising: a procedure in which the first SIP server transmits the fourth response message received from an adjacent node from a user-side I / F. System message exchange method. The second SIP server that manages the session information of the user terminal registers the common IP address as the source IP address, the IP address of the user terminal as the destination IP address, and the URI of the user terminal as the caller address and the callee address. A procedure for transferring the notification message registered with the ring side I / F to the adjacent node on one side,
Each node that has received the notification message from the adjacent node forwards the notification message from the ring side I / F to the adjacent node on one side;
The 1 SIP server to which the destination of the notification message is present in the ARP cache, and procedures for transmitting the notification message from the user I / F,
When the user terminal receives the notification message, its own IP address is registered as the source IP address, the common IP address is registered as the destination IP address, and the URI of the user terminal is registered as the sender address and the receiver address A procedure for sending back a fifth response message;
A procedure in which the first SIP server receives the fifth response message from a user-side I / F;
The first SIP server forwards the fifth response message from the ring side I / F to an adjacent node on one side;
Each node receiving the fifth response message from the adjacent node, a procedure for transferring the fifth response message from the ring side I / F to one side of the adjacent node,
The SIP network system message exchange method according to any one of claims 1 to 4, further comprising: a procedure in which the second SIP server receives the fifth response message received from an adjacent node.   6. The SIP network system message exchange method according to claim 1, wherein the first SIP server and the second SIP server are the same.   The SIP network system message exchange method according to any one of claims 1 to 5, wherein the first SIP server and the second SIP server are different.   8. The SIP network system message exchange method according to claim 1, wherein the message is discarded when the number of times of transfer between nodes exceeds a predetermined upper limit value.

Images