# Setting up an RTP VPC input RTP VPC input This section describes how to set up an upstream system that uses the RTP Push protocol to deliver source content from an upstream system that is in your Amazon Virtual Private Cloud (Amazon VPC). It describes how to set up the source content on the upstream system, and how to create an input that connects the upstream system to MediaLive. With an RTP VPC source, the upstream system *pushes* the content to MediaLive. To perform this setup, you must work with an Amazon VPC user, and with an operator at the upstream system. **Topics** + [ # Request setup on the VPC ](setup-vpc-rtp-vpc.md) + [ # Create an input for RTP push from Amazon VPC ](setup-input-rtp-vpc.md) + [ # Ensure correct setup on the upstream system ](setup-uss-rtp-vpc.md) + [ # Result of this procedure ](setup-rtp-vpc-result.md) # Request setup on the VPC Step 1: Set up VPC An Amazon VPC user must set up the VPC, and identify subnets and security groups that the upstream system and MediaLive will use. **To set up the VPC** 1. Provide the Amazon VPC user with the following guidelines. + Guideline for the subnets – Request two subnets. These rules apply: + You need two subnets because an RTP input is always a [standard-class input](class-channel-input.md), even if your channel is a single-pipeline channel. For information about input classes, see [Choosing the channel class and input class](class-channel-input.md). + The two subnets must be in different Availability Zones. + Each subnet must have a private CIDR block (a range of IP addresses). + Each subnet must have at least two unused addresses in that block—one for the upstream system and one for the RTP input. + Any other VPC-based sources (source B) that you create for use in the same channel as this RTP source (source A) must be in subnets that are in the same Availability Zones as source A. The two subnets of the source B can be different from the source A, but the Availability Zones of those two subnets must be the same as the Availability Zones of source A. + Guideline for the security group – The security group or groups for each subnet must follow these rules: + The combined rules of the security groups must allow inbound traffic from the IP addresses of the upstream system in that subnet. + The combined rules of the security groups must allow outbound traffic to port 5000. 1. After the Amazon VPC user has performed the setup, obtain the following information: + The ID of the VPC. For example: `vpc-3f139646` + The IDs of the two subnets. For example, one subnet might have this ID: `subnet-1122aabb` + The IDs of the security groups for the subnets. For example: `sg-51530134` # Create an input for RTP push from Amazon VPC Step 2: Create input After the Amazon VPC user has set up on the VPC, you can create the RTP VPC push input in MediaLive. **Topics** + [ ## Create the RTP input ](#rtp-vpc-push-create) + [ ## IAM role and ARN ](#rtp-push-role-and-remember-arn) ## Create the RTP input **To create an RTP VPC push input from Amazon VPC** 1. Make sure that you have the information from [step 1](setup-vpc-rtp-vpc.md). + The ID of the VPC. + The IDs of the two subnets. + The IDs of the security groups for the subnet or subnets. 1. Open the MediaLive console at [https://console.aws.amazon.com/medialive/](https://console.aws.amazon.com/medialive/). 1. In the navigation pane, choose **Inputs**. 1. On the **Inputs** page, choose **Create input**. 1. Complete the **Input details** section: + **Input** name – enter a name. + **Input type** – choose **RTP**. 1. In the **Network mode** section, choose **VPC**. 1. Complete the **VPC settings** section: + Choose **Select subnets and security groups**. + For **Subnets**, choose one of the subnets that you obtained. The dropdown list shows subnets in all VPCs, identified as follows: ` ` For example: **subnet-1122aabb us-west-2a 10.1.128.0/24 vpc-3f139646 Subnet for MLive push inputs** If the list of subnets is empty, choose **Specify custom VPC**, and enter the subnet ID in the field. (You need to enter only the subnet ID, for example, **subnet-1122aabb**.) + In **Subnets**, choose the second subnet. This second time, the dropdown list shows only the subnets in the same VPC as the first subnet. + For **Security groups**, choose the security group or groups that you obtained, following the same process as for the subnets. The dropdown list shows security groups belonging to the VPC that you chose, identified as follows: ` ` For example: **sg-51530134 Security group for MLive push inputs vpc-3f139646** 1. Complete the **Role ARN** section to choose a role for MediaLive to use with this input. For more information, see [IAM role and ARN](#rtp-push-role-and-remember-arn). 1. In the **Tags **section, create tags if you want to associate tags with this input. For more information, see [Tagging resources](tagging.md). 1. Choose **Create**. MediaLive creates the input and automatically creates two endpoints on that input. These endpoints have a private IP address from the subnet range, and they specify port 5000. For example: `rtp://10.12.30.44:5000` `rtp://10.99.39.15:5000`. 1. Provide the upstream system with these endpoints: + If you will set up the channel as a standard channel, provide both endpoints. The upstream system must push the content to both endpoints. + If you will set up the channel as a single-pipeline channel, provide only the first endpoint. The upstream system must push to this one endpoint. **Result of these procedures** As a result of this setup, each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTP input has two IP addresses. These addresses are fixed for the lifetime of the input, regardless of changes that occur (such as modifying other information in the input, or attaching the input to a different channel). Each address is in one of those subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. For a description of this setup that includes a diagram, see [Result of this procedure](setup-rtp-vpc-result.md) in the section about setting up an RTP VPC source. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. ## IAM role and ARN This section describes how to complete the **Role ARN** section on the **Create input** pane of the MediaLive console. You must choose a role for MediaLive to assume when it creates an RTP Push input. To create the input, MediaLive must obtain the network interfaces for the two endpoints in the input. These endpoints are in the CIDR range of the subnets that you identified. As soon as you choose **Create** for this input, MediaLive requests these network interfaces from Amazon VPC. The role that you choose ensures that MediaLive succeeds in its request to Amazon VPC. **Note** This section on the MediaLive console is identical to the **IAM role** section on the **Create channel** page (also on the MediaLive console). The difference in the two usages is that on the **Create input** page, you are attaching the role to the input. On the **Create channel** page, you are attaching the role to the channel. You can use the same role (for example, the **MediaLiveAccessRole**) in both usages. There are two general scenarios for choosing a role, depending on whether your organization has a designated administrator. ### Your organization has a designated administrator Your organization might have an administrator who manages this service. That administrator has likely set up one or more roles: + Ask the administrator or your manager which role to use. Or if only one role is listed in **Use existing role**, choose that role. + If the only role that is listed is **MediaLiveAccessRole**, choose that role. In addition, if the **Update** button is displayed beside this role name, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. ### Your organization has no administrator Your organization might not have a designated service administrator. In this case, if none of your colleagues have set up a suitable role, you might have to create one yourself and then choose it. + You can create the default role, called **MediaLiveAccessRole**. To first check if someone else has already created this role (only one person needs to create it for all users in your AWS account), look at **Create role from template**: + If this option is grayed out, this task has been done. In that case, choose **Use existing role**, and then choose **MediaLiveAccessRole** from the list. + If this option is not grayed out, choose **Create role from template**, and then choose **Create IAM role**. Next, choose that role from the list. If MediaLive does not let you create the role, speak to an administrator in your organization about your IAM permissions. + If the **MediaLiveAccessRole** has already been created and the **Update** button is displayed beside it, choose the button. (The button does not always appear, but whenever it does appear, choose it to refresh the role.) + If you want the selected role to appear first in the list next time, select **Remember ARN**. # Ensure correct setup on the upstream system Step 3: Set up upstream system You must make sure that the upstream system sets up correctly with your VPC and pushes content to the correct locations in MediaLive. **To set up for a standard channel** Follow this procedure if the MediaLive channel is a [standard channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, two subnets, and the security groups that the Amazon VPC user gave you. + The two endpoints (URLs) that MediaLive generated when you created the RTP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). The URLs have private IP addresses and include port 5000. For example: `10.12.30.44:5000` `10.99.39.15:5000` 1. Make sure that the operator sets up properly for a standard channel. They must: + Set up two output interfaces—one output interface in one of the subnets, and set up the other upstream system with one output interface in the other subnet. These interfaces are the addresses in the purple boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). + Deliver two sources that are identical in terms of video resolution and bitrate. + Push to the correct URLs on MediaLive. For example, they must push to: `10.12.30.131:5000` `10.99.39.40:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. **To set up for a single-pipeline channel** Follow this procedure if the MediaLive channel is a [single-pipeline channel](plan-redundancy.md). 1. Provide the operator with this information: + The IDs of the VPC, one subnet, and the security groups that the Amazon VPC user gave you. + Only the first of the two endpoints (URLs) that MediaLive generated when you created the RTP input. These endpoints are the addresses in the blue boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). The URL has a private IP address and includes port 5000. For example: `10.12.30.44:5000` `10.99.39.15:5000` 1. Make sure that the operator sets up properly for a standard channel. They must: + Set up one output interface. The interface is the address in one of the purple boxes in [the diagram after this procedure](setup-rtp-vpc-result.md). + Push to the correct URL on MediaLive. For example, they must push to: `10.12.30.131:5000` `10.99.39.40:5000` + Send over RTP, not UDP. The UDP protocol is not supported for an input into MediaLive. # Result of this procedure As a result of this setup, an RTP input exists that specifies one or two *endpoint* URLs. These endpoints are elastic network interfaces (ENIs) on your VPC. MediaLive has permission to use these ENIs for its inputs. MediaLive has permission (through the IAM trusted entity role) to automatically manage the ENIs for its inputs. The upstream system has permission, through the Amazon VPC security group, to push content to these endpoints. Each address is in one of those subnets. In this way, the delivery of the content from the upstream system to MediaLive takes place within the security of the VPC. The upstream system or systems have been set up to push the source content to the two endpoints (if you are setting up for a standard channel) or to one endpoint (if you are setting up for a single-pipeline channel). At least one VPC security group has been associated with each subnet. The CIDR block in each security group covers the two URLs that the upstream system pushes from, which ensures that MediaLive accepts the pushed content. Each output of the upstream system has an IP address in one of the specified subnets in your VPC. The RTP input has two IP addresses, and each address is in one of those subnets. In this way, the delivery of the source content from the upstream system to MediaLive takes place within the privacy of the VPC. Keep in mind that with a push input, the upstream system must be pushing the video source to the input when you start the channel. The upstream system does not need to be pushing before then. At runtime of the channel, MediaLive reacts to the content that is being pushed and ingests it. ![\[Diagram showing RTP input from upstream systems to MediaLive through VPC subnets.\]](http://docs.aws.amazon.com/medialive/latest/ug/images/rtp-vpc-uss-input.png)