Relay server, information registration method, and program

Abstract

To enable an administrator to easily grasp the status of communication between bases in a media transmission system that transmits and receives IP packetized media signals.SOLUTION: A relay server used in a media transmission system for transmitting and receiving IP packetized media signals between multiple locations includes an information acquisition unit that acquires information about a second location that is a communication partner of a first location where the relay server is located, and an information registration unit that determines a device name of the relay server on the basis of the information and registers the device name in an equipment management server.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to a media transmission system for transmitting and receiving IP packetized media signals. [Background technology]

[0002] In recent years, technology has been introduced that converts media signals such as video and audio captured by cameras and microphones into IP packets and transmits them. ST2110, established by the Society of Motion Picture and Television Engineers (SMPTE), is a standard for IP packetization of media signals. ST2110 specifies the method for converting broadcast video signals (SDI: Serial Digital Interface signals) into IP packets (Media over IP) and vice versa.

[0003] Additionally, a specification called NMOS (Network Media Open Specification) has been established to control the video and audio captured by cameras via IP in live production at broadcasting stations and outside broadcast vehicles. In NMOS, device information is registered in the RDS (Registration & Discovery System), and control is carried out based on the registered information. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2020-155988 A Summary of the Invention [Problem to be solved by the invention]

[0005] The connection of multiple bases, each controlled based on NMOS, is being considered. However, when a base is connected to one or more other bases, there is a problem in that it is difficult for the administrator of each base to grasp the communication status, such as which base it is communicating with and whether the communication between its own base and the other bases is normal.

[0006] The present invention has been made in consideration of the above points, and aims to provide a technique that enables an administrator to easily grasp the status of communication between base stations in a media transmission system that sends and receives IP packetized media signals. [Means for solving the problem]

[0007] According to the disclosed technology, there is provided a relay server used in a media transmission system for transmitting and receiving IP packetized media signals between a plurality of locations, comprising: an information acquisition unit that acquires information about a second location that is a communication partner of a first location where the relay server is located; an information registration unit that determines a device name of the relay server based on the information and registers the device name in a device management server; A relay server is provided. Effect of the Invention

[0008] The disclosed technique provides a technique that allows an administrator to easily grasp the state of communication between bases in a media transmission system that transmits and receives IP packetized media signals. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating an example of a network extension method. [Diagram 2] FIG. 1 is a diagram illustrating an example of an inter-domain connection method. [Diagram 3] FIG. 1 is a diagram showing an image of connecting bases using an inter-domain connection method. [Figure 4]1 is a diagram illustrating an example of the configuration of a media transmission system according to an embodiment of the present invention. [Diagram 5] FIG. 11 is a diagram for explaining example 1 of information registration in the device management server. [Figure 6] FIG. 11 is a diagram for explaining example 2 of information registration in the device management server. [Figure 7] FIG. 11 is a diagram for explaining example 3 of information registration in the device management server. [Figure 8] FIG. 13 is a diagram showing an example of a display on a terminal. [Figure 9] FIG. 13 is a diagram illustrating another example of a system configuration. [Figure 10] FIG. 11 is a diagram for explaining sequence example 1. [Figure 11] FIG. 11 is a diagram for explaining sequence example 2. [Figure 12] FIG. 11 is a diagram for explaining sequence example 3. [Figure 13] FIG. 11 is a diagram for explaining sequence example 4. [Figure 14] FIG. 11 is a diagram for explaining sequence example 5. [Figure 15] FIG. 11 is a diagram for explaining sequence example 6. [Figure 16] FIG. 13 is a diagram for explaining sequence example 7. [Figure 17] 2 is a diagram illustrating an example of a functional configuration of a relay server 100. FIG. [Figure 18] FIG. 2 is a diagram illustrating an example of a hardware configuration of a relay server 100. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, an embodiment of the present invention (the present embodiment) will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0011] In the following, video will be mainly used as an example, but the technology described below is not limited to video and can be applied to media signals in general, such as audio and data.

[0012] (About connections between video domains) The following two methods (1) and (2) can be considered as a method for connecting a video domain constructed with ST2110-compatible devices at a certain site to a video domain at a remote site.

[0013] (1) Network expansion method An example of a network expansion method is shown in Figure 1. In the example shown in Figure 1, the main base is equipped with ST2110-compatible devices including ST2110-compatible SW, and is controlled by an NMOS controller.

[0014] As shown in Figure 1, in the network extension method, the local network at the main site is extended at the L2 level, and ST2110-compatible devices at remote sites are installed within that network. The ST2110-compatible devices at the main site and those at remote sites are used under the same NMOS controller.

[0015] In the network expansion method, the wide area network requires a bandwidth for all the multicast media streams in which devices connected to remote locations participate.

[0016] (2) Inter-domain connection method An example of an inter-domain connection method is shown in Fig. 2. In the example shown in Fig. 2, a video NW (video domain) on the sending side and a video NW (video domain) on the receiving side are connected by a wide area NW via a termination device.

[0017] The sending video network and the receiving video network are each equipped with an NMOS controller, and the sending video network and the receiving video network are independent video networks with different administrators. In the inter-domain connection method, these video networks are logically connected and only necessary signals are sent and received.

[0018] With the inter-domain connection method, the network bandwidth required in the wide area network is only the amount of feed that needs to be exchanged between bases.

[0019] This embodiment is directed to an inter-domain connection method, which is expected to be applied to, for example, connections between different companies, material transmission between different broadcasting stations, and the like.

[0020] (About the assignment) The basic specifications of media IP transmission assumed in this embodiment include the above-mentioned ST2110 and NMOS.

[0021] ST2110 is a standard for converting media (video, audio, and auxiliary data) to IP with ultra-low latency. NMOS (IS-04, IS-05) is a standard for registering and switching media-related devices.

[0022] An image of connecting bases using the inter-domain connection method is shown in Fig. 3. In this embodiment, the inter-domain connection shown in Fig. 3 is realized while performing control based on NMOS at each base. In the configuration shown in Fig. 3, large volumes of video data flow through the network between bases with ultra-low latency.

[0023] As shown in Figure 3, in a configuration in which independent, remote locations (e.g., broadcasting stations) are connected via a network, the administrator of each location needs to know the status of communications, such as the location to which it is connected (which other location it is connected to) and whether video is being reliably transmitted to the destination location.

[0024] However, in conventional technology, there is no easy way to grasp the communication status. In particular, when multicast is used in IP communication, the receiver receives the multicast by joining a multicast group, so it is difficult for the sender to grasp who is receiving the multicast. Therefore, for example, the administrator needs to call the connected base to check the communication status, which is inefficient.

[0025] The system configuration and operation for solving the above problems will be described below.

[0026] (System configuration example) An example of the configuration of a media transmission system according to this embodiment is shown in Fig. 4. In the example shown in Fig. 4, a point X (ST2110 local domain X) and a point Y (ST2110 local domain Y) are connected via a NW (network) service.

[0027] A relay server 100 that executes operations to solve the problem is provided for each base. Also, an NMOS controller 300 and a device management server 200 are provided for each base.

[0028] As shown in Fig. 4, site X is equipped with a source of video and the like having a camera (CAM) and an IP-based GW. Media such as video is converted into IP packets by the IP-based GW, and the IP packets are transmitted to the destination site Y by the ST2110-compliant SW.

[0029] The GMC is the source of reference time when performing high-precision time synchronization using PTP (Precision Time Protocol).

[0030] Site Y is equipped with an ST2110 compatible SW and GMC, as well as an SDI conversion GW and an ST2110 compatible editing machine, which allow editing and monitoring of video and the like.

[0031] An example of the operation of the device management server 200 and the NMOS controller 300 based on the existing technology defined in the NMOS specifications (IS-04, IS-05) will be described.

[0032] The device management server 200 provided at each base is a device equivalent to an RDS (which may be called an NMOS registry). In each local domain, each of all devices (NMOS nodes) discovers the device management server 200 and registers its own device information (such as device name) in the device management server 200. The relay server 100 is included in all the devices.

[0033] The NMOS controller 300 acquires registered device information from the device management server 200 .

[0034] Also, in each local domain, the NMOS controller 300 can obtain, based on device information, for example, the SDP (Session Description Protocol) of the transmitting device, etc., and issue a video switching command to devices such as the receiving device.

[0035] <Regarding the relay server 100> The relay server 100 performs address conversion, etc., on the media stream in the local domain and transfers it to another device. The relay server 100 can also transfer the stream to multiple destinations. The relay server 100 also receives streams from other local domains. In addition, the relay server 100 has functions corresponding to state acquisition API requests, video reception start API requests, and stop API requests from the NMOS controller 300.

[0036] Also, the relay server 100 communicates with the relay server 100 in other local domains to obtain information about other local domains, and registers the device name (which may be called the node name) determined based on that information with the device management server 200. The relay server 100 also deletes information registered in the device management server 200.

[0037] It is assumed that the relay server 100 registers information with the device management server 200 according to the procedures in accordance with the NMOS specifications, but it is not limited to the procedures in accordance with the NMOS specifications.

[0038] <Basic functions of the NW service> The NW service shown in FIG. 4 connects multiple sites and provides a network that can be used for the transmission of multiple types of media. In this NW service, a private cloud may be built at one of the sites. In the private cloud, for example, media storage / editing and Internet distribution are performed using a server. Also, it is possible to copy media and send it to multiple sites through the NW service.

[0039] (Example of operation of relay server 100) The relay server 100 at a certain base can change the name of the relay server 100 registered in the device management server 200 according to a change in the state of communication with other bases. This allows the terminal displaying the information registered in the device management server 200 to display information such as the current video transmission destination base and whether the communication is normal.

[0040] Specifically, at each base, the relay server 100 registers in the device management server 200 a name by which the video transmission source base or the video transmission destination base can be identified.

[0041] Furthermore, when the relay server 100 detects a status change at the opposite site, it changes the registered information in the device management server 200 accordingly. Any method of change may be used as long as the user (administrator) of the terminal where the information is displayed can recognize the content of the status change. One example is a description method in which a status such as NA (Not Available) is added to the device name, or an error ID is added to the device name.

[0042] Below, examples 1 to 3 will be described as operation examples. The "base" in examples 1 to 3 is not limited to a specific one, but may be, for example, a stadium where a sports match is held, or a broadcasting station. In the following examples 1 to 3, it is assumed that the "base" is a stadium, and "Stadium" is used as the name (device name) of the registration information.

[0043] <Example 1> Example 1 will be described with reference to Fig. 5. As shown in Fig. 5, in Example 1, a relay server 100A at a site A transmits video to a relay server 100B at a site B.

[0044] At this time, the relay server 100A registers the ID of the relay server 100A and "StadiumB" as the name (device name, node name) of the relay server 100A in the table of the device management server 200A. "StadiumB" indicates that the destination of the video transmitted by the relay server 100A is the site B (i.e., StadiumB).

[0045] In addition, the relay server 100B registers the ID of the relay server 100B and "StadiumA" as the name of the relay server 100B in the table of the device management server 200B. "StadiumA" indicates that the source of the video received by the relay server 100B is the site A (i.e., StadiumA).

[0046] <Example 2> Example 2 will be described with reference to Fig. 6. As shown in Fig. 6, in Example 2, a network interruption occurs between site A and site B while a relay server 100A at site A is transmitting video to a relay server 100B at site B. The state immediately before the network interruption occurs is the same as in Example 1. Here, the changes from Example 1 will be described.

[0047] When the relay server 100A detects the network outage, it adds NA to the name of the relay server 100A, "StadiumB", in the table of the device management server 200A, creating "NA_StadiumB". "NA_StadiumB" means that video transmission to the site B is no longer possible.

[0048] In addition, when the relay server 100B detects the network disconnection, the relay server 100B adds E123 as an error ID to the name of the relay server 100B, "StadiumA," in the table of the device management server 200B, creating "E123_StadiumA." "E123_StadiumA" means that video reception from the site A is no longer possible.

[0049] <Example 3> In Example 3, the relay server 100 on the transmitting side transmits video by multicast. The relay server 100 on the receiving side can receive video transmitted from the relay server 100 on the transmitting side by joining a multicast group. Therefore, it is expected that the number of relay servers 100 on the receiving side that are opposite to the relay server 100 on the transmitting side will increase or decrease from time to time.

[0050] When the transmitting relay server 100 detects that the number of the opposing relay servers 100 has increased or decreased, it may change the already registered name or may separate the IDs according to the number of the opposing relay servers 100.

[0051] An example of changing an already registered name will be described with reference to Fig. 7. In Example 3, as shown in Fig. 7, from the state of Example 1 (Fig. 5), relay server 100C at site C is added as a destination of video transmission by relay server 100A at site A. The state immediately before relay server 100C is added is the same as Example 1. Here, the change from Example 1 will be described with a focus on site A.

[0052] When relay server 100A detects that relay server 100C has been added as a receiver, it adds "Stadium C" to "Stadium B", which is the name of relay server 100A, in the table of device management server 200A, making it "Stadium B / Stadium C." "Stadium B / Stadium C" indicates that the receivers of the video transmitted from relay server 100A are sites B and C.

[0053] When the ID is to be divided according to the number of counterparts, the relay server 100A adds, for example, a record of "ID=ID2 of the relay server 100A, device name=StadiumC" to the table of the equipment management server 200A.

[0054] (Example of display on device) As described above, the information registered in the device management server 200 can be displayed on a terminal at each base. By looking at the information displayed on the terminal, the administrator can grasp the status of video transmission at the base.

[0055] A display example (visualization example) at site A will be described with reference to Fig. 8. The connection state corresponding to the display example is shown on the left side of Fig. 8. As shown on the left side of Fig. 8, this connection state is the same as the connection state shown in Fig. 7.

[0056] Therefore, in this state, for example, "ID=ID1 of relay server 100A, device name=StadiumB" and "ID=ID2 of relay server 100A, device name=StadiumC" are registered in the table of device management server 200A.

[0057] The above information indicates that the sender is location A, and the receivers relative to the sender are locations B and C. A terminal that has acquired the above information displays, for example, the information shown on the right side of FIG.

[0058] In this embodiment, it is assumed that the status can be registered and displayed for each video source. In the example of Figure 8, it is shown that for video source 1, the sender is location A, and the receivers for the sender are locations B and C.

[0059] (Other configuration examples) As shown in Fig. 9, by providing a relay SW 400 on a service network, it is possible to configure a system in which multiple relay servers 100 are connected. In the example of Fig. 9, in addition to site A, site B, site X, and site Y, a cloud site is also shown.

[0060] Each base station is equipped with an ST2110-compliant device for transmitting and receiving video, an NMOS controller 300, a device management server 200, and a relay server 100. For convenience of illustration, only the relay server 100 is shown in Fig. 9 at each base station.

[0061] As already explained, the relay server 100 at each base can register information such as the base to which the connection is made to the device management server 200 and display it on the terminal. Also, the relay server 100 at each base can register in the device management server 200 that the video has been delivered to the destination base without fail and display it on the terminal.

[0062] This system also includes a management server 500 that monitors and manages the network, as shown in Fig. 9. The management server 500 has a schedule reservation function. The management server 500 can execute the following processes using the schedule reservation function.

[0063] The management server 500, in addition to monitoring and managing the network, collects and stores the above-mentioned transmission / reception confirmation information from each relay server 100. Based on the collected information, the management server 500 can respond to inquiries about the situation at each time.

[0064] In addition, the management server 500 instructs the relay server 100 to use resources reserved in advance by the user, so that the transmission and reception resources in the network and the server do not exceed the available resources. The relay server 100 changes the state to make the connection using the resource possible. This makes it possible to prevent resource usage conflicts.

[0065] (Sequence example) Below, sequence examples 1 to 7 using the relay server 100 will be described. In the following examples, information is requested and acquired by HTTP communication, but the communication protocol used is not limited to HTTP. Information may be requested and acquired by a communication protocol other than HTTP.

[0066] Among sequence examples 1 to 7, sequence examples 1 and 2 show basic sequence examples, while sequence examples 3 to 7 show sequence examples in more specific situations.

[0067] <Sequence example 1> Sequence example 1 will be described with reference to Fig. 10. In sequence example 1, a one-to-one connection is established between site A and site B, and an example will be described in which a node name (device name) is updated.

[0068] In S1, the relay server 100A transmits a Ping to the relay server 100B. In S2, the relay server 100A transmits an ACK to the relay server 100B. This allows a communication check to be performed.

[0069] In S3, the relay server 100A requests the stream information from the relay server 100B, and receives the stream information in S4.

[0070] In S5, the relay server 100A determines the node name (the name of the relay server 100A), and updates the node name if an update is necessary.

[0071] In S6, the Relay Server 100A transmits the current node name to the device management server 200A. In S7, the Relay Server 100A receives a response indicating the success or failure of the update from the device management server 200A.

[0072] The above process is a process from relay server 100A to relay server 100B, but the same process is also asynchronously performed from relay server 100B to relay server 100A.

[0073] 10 is executed at regular intervals, for example. If the device management server 200 does not receive a notification from the relay server 100 about certain information for a certain period of time, the device management server 200 deletes the information from the registration.

[0074] Each node (relay server 100 in FIG. 10) periodically reports its own survival status to the device management server 200, and the node name may be notified (changed) at that timing. Also, the node name may be notified (changed) asynchronously with the survival status report.

[0075] Concerning stream information, if the responding side is the stream sender, it returns at least one of the following as stream information: "Stream source / destination address", "transmission rate", etc. If the responding side is the stream receiver, it returns at least one of the following as stream information: "Stream source / destination address", "reception rate", "retransmission rate", "number of packet losses that have occurred since the last response", etc.

[0076] In determining and updating the node name, the relay server 100 updates the node name from the information acquired by Ping or HTTP. For example, if no Ack is returned, the node name is "NotAvailable", if the Src / Dst address of the stream is different, the node name is "UsedBySomeone", if the sending rate or receiving rate is 0, the node name is "Stop", if the sending rate and receiving rate do not match, the node name is "BandError", if packet loss has occurred, the node name is "Loss", if the retransmission rate is not 0, the node name is "ReTransport", etc.

[0077] The correspondence between the occurrence event and the character string to be added may be determined arbitrarily. Also, the name of the remote site itself may be deleted. In other words, the node name (device name) does not have to include the name of the remote site.

[0078] Ping and HTTP may be replaced with other common methods, such as proprietary TCP or UDP, or HTTPS including encryption, instead of HTTP.

[0079] <Sequence example 2> Next, sequence example 2 will be described with reference to Fig. 11. This example is an example of 1-to-N connection in which multiple locations are connected to location A. N is the total number of opposing relay servers. As shown in Fig. 11, the processing with the relay server 100B described in sequence example 1 is performed with each opposing relay server 100.

[0080] That is, in the case of 1:N, the relay server 100A checks communication and acquires stream information from all of the opposing relay servers 100. The determination and update of node names, and notification of node names to the device management server 200A are performed for each location. The node name registered in the device management server 200A may represent information for multiple locations with one node name. Also, a different node name may be used for each location.

[0081] <Sequence example 3> Sequence example 3 will be described with reference to Fig. 12. Sequence example 3 is a sequence when a transmission path is established between point A and point B. In addition to a relay server 100 and a device management server 200, a user terminal 10 and a media transmitter / receiver 20 are shown at each point. The user terminal 10 is equipped with a browser and is capable of displaying information via a Web UI.

[0082] When a user at point A performs a transmission path establishment operation on the user terminal 10A, the user terminal 10A instructs the relay server 100A to establish a transmission path to point B in S1.

[0083] In S2, the relay server 100A inquires of the relay server 100B whether transmission is possible. In S3, the relay server 100B notifies the relay server 100A whether transmission is possible. In S4, the relay server 100A notifies the relay server B of the name of the base A.

[0084] In S5, the relay server 100B notifies the device management server 200B of a change request for the device name. This change request is a request to change the device name of the relay server 100B according to the name notified by the relay server 100A. Specifically, immediately after the transmission path is established, the media stream is not being transmitted and the state is stopped. Therefore, in S5, for example, a change request is sent to change the device name of the relay server 100B to "Site A: (stopped)".

[0085] In S6, the equipment management server 200B notifies the user terminal 10B of the updated device name. As a result, the device name of the relay server 100B is displayed on the user terminal 10B. This allows the user to confirm the location of the other party to which the media is to be transmitted.

[0086] In S7, the device management server 200B notifies the relay server 100B of the success or failure of the change.

[0087] In S8, the relay server 100B notifies the name of the site B to the relay server 100A.

[0088] In S9, the relay server 100A notifies the device management server 200A of a change request for the device name. This change request is a request to change the device name of the relay server 100A according to the name notified by the relay server 100B. Specifically, immediately after the transmission path is established, the media stream is not being transmitted and the state is stopped. Therefore, in S9, for example, a change request is sent to change the device name of the relay server 100A to "Site B: (stopped)".

[0089] In S10, the equipment management server 200A notifies the user terminal 10A of the updated device name. As a result, the device name of the relay server 100A is displayed on the user terminal 10A. This allows the user to confirm the location of the other party's base with which media communication is to be performed.

[0090] <Sequence example 4> Sequence Example 4 will be described with reference to Fig. 14. In Sequence Example 4, a sequence at the start of media transmission between site A and site B will be described. In addition to a relay server 100 and a device management server 200, a user terminal 10 and a media transmitter / receiver 20 are shown at each site. The user terminal 10 is equipped with a browser and is capable of displaying information via a Web UI.

[0091] When a user at site A performs a media reception operation on the user terminal 10A, in S1, the user terminal 10A transmits a media reception instruction to the relay server 100A. In S2, the relay server 100A joins the multicast group of the stream transmitted from the media sender 20A. In S3, the relay server 100A receives the stream transmitted from the media sender 20A.

[0092] In S4, the relay server 100A issues a reception instruction to the relay server 100B by notifying the relay server 100A of the transmission state and the media information. In S5, the relay server 100B joins the multicast group of the stream based on the notified media information. In S6, the relay server 100B receives the media stream.

[0093] In S7, the relay server 100B notifies the device management server 200B of a request to change the device name. This request is to change the device name of the relay server 100B according to the transmission status of the relay server 100A and the information of the transmitting media.

[0094] For example, when relay server 100B finds that relay server 100A is transmitting 2K video, it transmits a change request to device management server 200B to change the device name of relay server 100B to, for example, "site A: (receiving: 2K)."

[0095] In S8, the equipment management server 200B notifies the user terminal 10B of the updated device name. As a result, the device name of the relay server 100B is displayed on the user terminal 10B. This allows the user to check whether media is being transmitted from the remote location and what kind of media it is.

[0096] In S9, the equipment management server 200B notifies the relay server 100B of the success or failure of the change.

[0097] In S10, the relay server 100B notifies the relay server 100A of the reception state of the relay server 100B.

[0098] In S11, the Relay Server 100A notifies the device management server 200A of a request to change the device name. This request is a request to change the device name of the Relay Server 100A according to the reception status of the Relay Server 100B.

[0099] For example, when the relay server 100A finds out that the relay server 100B is receiving video with no packet loss, the relay server 100A sends a change request to the equipment management server 200A to change the device name of the relay server 100A to, for example, “Location B: (transmitting: no packet loss).”

[0100] In S12, the equipment management server 200A notifies the user terminal 10A of the updated device name. As a result, the device name of the relay server 100A is displayed on the user terminal 10A. This allows the user to check whether the media is being transmitted to the remote location. In S13, the equipment management server 200A notifies the relay server 100A of the success or failure of the change.

[0101] When the user at site B performs a media receiving operation on the user terminal 10B, in S14 a receiving instruction is transmitted to the media receiver 20B. In S15, the media receiver 20B joins the multicast group of the stream transmitted from the relay server 100B. In S16, the media receiver 20B receives the media stream transmitted from the relay server 100B.

[0102] <Sequence Example 5> Sequence Example 5 will be described with reference to Fig. 14. In Sequence Example 5, a sequence when media transmission between site A and site B is stopped will be described. In addition to a relay server 100 and a device management server 200, a user terminal 10 and a media transmitter / receiver 20 are shown at each site. The user terminal 10 is equipped with a browser and is capable of displaying information via a Web UI.

[0103] When a user at site A performs a media reception stop operation on the user terminal 10A, in S1, the user terminal 10A transmits a media reception stop instruction to the relay server 100A. In S2, the relay server 100A leaves the multicast group of the stream transmitted from the media sender 20A. In S3, the relay server 100A stops receiving the stream transmitted from the media sender 20A.

[0104] In S4, the relay server 100A issues a reception stop instruction to the relay server 100B by notifying the relay server 100A of the transmission state of the relay server 100A. In S5, the relay server 100B leaves the multicast group of the stream based on the notified media information.

[0105] In S6, the relay server 100B notifies the device management server 200B of a request to change the device name. This request is a request to reflect the stop of transmission from the relay server 100A in the device name of the relay server 100B.

[0106] For example, when the relay server 100B finds out that the relay server 100A is in a transmission stopped state, the relay server 100B transmits a change request to the device management server 200B to change the device name of the relay server 100B to, for example, "Site A: (stopped)."

[0107] In S7, the equipment management server 200B notifies the user terminal 10B of the updated device name. As a result, the device name of the relay server 100B is displayed on the user terminal 10B. This allows the user to confirm that the media stream from the remote location has stopped.

[0108] In S8, the device management server 200B notifies the relay server 100B of the success or failure of the change. In S9, the relay server 100B notifies the relay server 100A of the reception status of the relay server 100B.

[0109] In S10, the relay server 100A notifies the device management server 200A of a request to change the device name. This request is to reflect the fact that reception at the relay server 100B has been stopped in the device name of the relay server 100A.

[0110] For example, when the relay server 100A finds that the relay server 100B is in a reception stopped state, the relay server 100A transmits a change request to the device management server 200B to change the device name of the relay server 100A to, for example, "Site B: (stopped)."

[0111] In S11, the device management server 200A notifies the user terminal 10A of the updated device name. As a result, the device name of the relay server 100A is displayed on the user terminal 10A. This allows the user to confirm that the remote location has stopped waiting for the media stream. In S12, the device management server 200A notifies the relay server 100A of the success or failure of the change.

[0112] <Sequence Example 6> Sequence Example 6 will be described with reference to Fig. 15. In Sequence Example 6, a sequence will be described in the case where a network interruption occurs between base A and base B. In addition to a relay server 100 and a device management server 200, a user terminal 10 and a media transmitter / receiver 20 are shown at each base. The user terminal 10 is equipped with a browser and is capable of displaying information via a Web UI.

[0113] At S1, a network interruption occurs. The relay server 100B periodically checks the reception state, and at S2, detects the network interruption from a drop in the transmission rate of the media stream, a link down, or the like.

[0114] In S3, the relay server 100B notifies the device management server 200B of a request to change the device name. This request is to reflect the network disconnection in the device name of the relay server 100B.

[0115] For example, when the relay server 100B detects a network outage between the relay server 100A and the relay server 100B, the relay server 100B transmits a change request to the device management server 200B to change the device name of the relay server 100B to, for example, "Location A: (Network outage)."

[0116] In S4, the device management server 200B notifies the user terminal 10B of the updated device name. As a result, the device name of the relay server 100B is displayed on the user terminal 10B. This allows the user to confirm that a network interruption has occurred between the user terminal 10B and the remote site. In S5, the device management server 200B notifies the relay server 100B of the success or failure of the change.

[0117] The relay server 100A periodically checks the reception status of the relay server 100B (S6). In S7, when the relay server 100B detects a network interruption based on the absence of a response or the reception status of the relay server 100B, the relay server 100B notifies the relay server 100A of the reception status of the relay server 100B (a status indicating a network interruption). In S8, the relay server 100A notifies the device management server 200A of a request to change the device name. This request is a request to reflect the network disconnection in the device name of the relay server 100A.

[0118] For example, when the relay server 100A detects a network outage between the relay server 100A and the relay server 100B, the relay server 100A transmits a change request to the device management server 200A to change the device name of the relay server 100A to, for example, "Location B: (Network outage)."

[0119] In S9, the device management server 200A notifies the user terminal 10A of the updated device name. As a result, the device name of the relay server 100A is displayed on the user terminal 10A. This allows the user to confirm that a network interruption has occurred between the user terminal 10A and the remote site. In S10, the device management server 200A notifies the relay server 100A of the success or failure of the change.

[0120] <Sequence Example 7> Sequence example 7 will be described with reference to Fig. 16. In sequence example 7, an example of scheduling will be described.

[0121] When a user at location A sets a schedule on user terminal 10A to "switch from location B to location C after a certain period of time," in S1, user terminal 10A instructs relay server 100A to "switch from location B to location C after a certain period of time."

[0122] In S2, the relay server 100A notifies the user terminal 10A of the success or failure of the change. In S3, the relay server 100A executes a timer process.

[0123] In S4, the relay server 100A issues a reception stop instruction to the relay server 100B by notifying the relay server 100A of the transmission state of the relay server 100A. In S5, the relay server 100B leaves the multicast group of the stream transmitted from the relay server 100A. In S6, the relay server 100B stops receiving the media stream.

[0124] In S7, the relay server 100B notifies the device management server 200B of a request to change the device name. This request is to reflect the fact that the transmission path from the relay server 100A is no longer available in the device name of the relay server 100B.

[0125] For example, when the relay server 100B finds out that the transmission path to the relay server 100A has been lost, the relay server 100B transmits a change request to the device management server 200B to change the device name of the relay server 100B to "no base", for example.

[0126] In S8, the equipment management server 200B notifies the user terminal 10B of the updated device name. As a result, the device name of the relay server 100B is displayed on the user terminal 10B. This allows the user to confirm the deletion of the transmission path to the remote site.

[0127] In S9, the device management server 200B notifies the relay server 100B of the success or failure of the change. In S10, the relay server 100B notifies the relay server 100A of the reception status of the relay server 100B.

[0128] In S11, the relay server 100A issues a reception instruction to the relay server 100C by notifying the relay server 100A of the transmission state and the media information. In S12, the relay server 100C joins the multicast group of the stream based on the notified media information. In S13, the relay server 100C receives the media stream.

[0129] In S14, the relay server 100C notifies the device management server 200C of a request to change the device name. This request is to change the device name of the relay server 100C according to the transmission status of the relay server 100A and the information of the transmitting media.

[0130] For example, when relay server 100C finds that relay server 100A is transmitting 2K video, it transmits a change request to device management server 200C to change the device name of relay server 100C to, for example, "site A: (receiving: 2K)."

[0131] In S15, the equipment management server 200C notifies the user terminal 10C of the updated device name. As a result, the device name of the relay server 100C is displayed on the user terminal 10C. This allows the user to confirm whether a transmission path has been added and whether media is being transmitted from the remote location, and what kind of media it is.

[0132] In S16, the device management server 200C notifies the relay server 100C of the success or failure of the change.

[0133] In S17, the relay server 100C notifies the relay server 100A of the reception state of the relay server 100C.

[0134] In S18, the relay server 100A notifies the device management server 200A of a request to change the device name. This request is a request to change the device name of the relay server 100A according to the reception status of the relay server 100C.

[0135] For example, when the relay server 100A finds that the relay server 100C is receiving video with no packet loss, the relay server 100A transmits a change request to the device management server 200A to change the device name of the relay server 100A to, for example, “Location C: (transmitting: no packet loss).”

[0136] In S19, the device management server 200A notifies the user terminal 10A of the updated device name. As a result, the device name of the relay server 100A is displayed on the user terminal 10A. This allows the user to confirm that the remote location has been switched. In S20, the device management server 200A notifies the relay server 100A of the success or failure of the change.

[0137] (Example of functional configuration of relay server 100) Fig. 17 shows an example of the functional configuration of the relay server 100. As shown in Fig. 17, the relay server 100 includes a transfer unit 110, an information acquisition unit 120, and an information registration unit 130. Note that the transfer unit 110 may be provided outside the relay server 100. Also, the relay server may be called a relay device.

[0138] The transfer unit 110 transfers a media stream in a local domain to another device after performing address conversion, etc. The transfer unit 110 can also transfer a stream to multiple destinations. The transfer unit 110 also receives streams from other local domains.

[0139] The information acquisition unit 120 acquires information about other bases that are communication partners of the base where the relay server 100 is installed. Specifically, for example, the information can be acquired using the processing procedures described in sequence examples 1 to 7. The information registration unit 130 determines a device name of the relay server 100 based on the information, and registers the device name in the equipment management server 200.

[0140] (Hardware configuration example) The relay server 100 described in this embodiment can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on the cloud.

[0141] That is, the relay server 100 can be realized by executing a program corresponding to the processing performed by the relay server 100 using hardware resources such as a CPU and memory built into a computer. The above program can be recorded on a computer-readable recording medium (such as a portable memory) and can be stored or distributed. The above program can also be provided via a network such as the Internet or email.

[0142] Fig. 18 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 18 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are connected to each other via a bus B. The computer may further include a GPU.

[0143] The program for realizing the processing on the computer is provided by a recording medium 1001 such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0144] The memory device 1003 reads out and stores the program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the relay server 100 in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to a program. The input device 1007 is composed of a keyboard and mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0145] (Effects of the embodiment) As described above, the technology described in this embodiment enables an administrator to easily grasp the state of communication between bases in a media transmission system that transmits and receives IP packetized media signals. Also, it becomes easy to control the transmission of media signals between bases.

[0146] The following supplementary notes are further disclosed regarding the above embodiment.

[0147] <Additional Notes> (Additional note 1) A relay server used in a media transmission system for transmitting and receiving IP packetized media signals between multiple locations, comprising: an information acquisition unit that acquires information about a second location that is a communication partner of a first location where the relay server is located; an information registration unit that determines a device name of the relay server based on the information and registers the device name in a device management server; A relay server comprising: (Additional note 2) The device name includes information that indicates the second location. The relay server described in appended paragraph 1. (Additional note 3) The device name includes information indicating a state between the first location and the second location. 3. The relay server according to claim 1 or 2. (Additional note 4) The information registration unit changes the device name in response to an increase or decrease in the number of locations receiving the stream distributed by multicast from the first location. 4. The relay server according to claim 1, (Additional note 5) 5. The relay server according to claim 1, further comprising a transfer unit for transferring IP packetized media signals. (Additional note 6) 1. An information registration method executed by a relay server used in a media transmission system for transmitting and receiving IP packetized media signals between multiple locations, comprising the steps of: an information acquisition step of acquiring information about a second location that is a communication partner of a first location where the relay server is installed; an information registration step of determining a device name of the relay server based on the information and registering the device name in a device management server; The information registration method includes: (Additional note 7) A non-transitory storage medium storing a program for causing a computer to function as each unit in the relay server according to any one of claims 1 to 5.

[0148] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and variations are possible within the scope of the gist of the present invention described in the claims. [Explanation of symbols]

[0149] 100 Relay Server 110 Transfer Unit 120 Information Acquisition Department 130 Information Registration Department 200 Device management server 300 NMOS Controller 400 Relay SW 500 Management Server 1000 Drive Device 1001 Recording media 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input Device 1008 Output device

Claims

1. A relay server used in a media transmission system for transmitting and receiving IP packetized media signals between a plurality of locations, comprising: an information acquisition unit that acquires information about a second location that is a communication partner of a first location where the relay server is located; an information registration unit that determines a device name of the relay server based on the information and registers the device name in a device management server; A relay server comprising:

2. The device name includes information that indicates the second location. The relay server according to claim 1 .

3. The device name includes information indicating a state between the first location and the second location. The relay server according to claim 1 .

4. The information registration unit changes the device name in response to an increase or decrease in the number of locations receiving the stream distributed by multicast from the first location. The relay server according to claim 1 .

5. The relay server according to claim 1 , further comprising a transfer unit for transferring IP packetized media signals.

6. 1. An information registration method executed by a relay server used in a media transmission system for transmitting and receiving IP packetized media signals between a plurality of locations, comprising the steps of: an information acquisition step of acquiring information about a second location that is a communication partner of a first location where the relay server is located; an information registration step of determining a device name of the relay server based on the information and registering the device name in a device management server; The information registration method includes:

7. A program for causing a computer to function as each unit in the relay server according to any one of claims 1 to 5.

Images