Implementing Triton Tap on a Revma station

Modified on Mon, 22 Jul at 1:19 PM

This article will navigate an account administrator through the Session Rules, found on the account level of the Revma UI, in order to implement and trigger Vast calls towards Triton.


Session Rules refer to a filtering method, that allows users to route the listeners through a certain stream or a group of streams, with various actions being applied. 


Specifically for serving VAST content the following are needed:

  1. An action

  2. A content provider (in our case Triton)

  3. A rule



TABLE OF CONTENTS




General Overview


Action


The first step towards VAST implementation is to create a specific Vast action. Using the VAST action, allows media to be served on (a group of) listeners, using a VAST compatible provider’s inventory. These media can be served upon a listener’s connection (preRoll) and/or during the listeners connection (midRoll).






Content Provider


In this section of the Session Rules is where content providers can be added. These are the ad providers that can be used by rules that contain the Vast action.


To add a provider you will first need to enter a URL from which pre-roll ads will be served and a Midroll URL from which midroll ads will be served.


Under Type is where the content provider’s type can be selected. This is required to be correct in order for the content provider to function properly, as different provider’s use different settings.


Furthermore, under the content provider section, there are several other option for a user to choose from:


Append Listener Id: This indicates whether or not to append the listenerId query parameter in the VAST request. By default this is selected as active. It’s advisable that the Append Listener Id box remains ticked at all times, as, including the listener id in the ad request URL, more targeted advertisements will be generated.


Delay Report: This indicates whether or not to report VAST impressions and tracking events with a delay. By default this is not selected as active; however, the Delay Report is best kept ticked, as it delays the reports coming through by a few seconds, in order to balance the misbehavior of different web players.


Sequential: This indicates whether or not to perform sequential requests to this provider until no or empty response. Only then, the next request will be made to the next provider. By default this is not selected as active.


Append Listener Query: This indicates whether or not to append the listener's query parameters in the VAST request. By default this is not selected as active.


Cache Response: Property to indicate whether or not to cache VAST responses. By default this is not selected as active. In case companion ads are being served by the provider, this needs to be enabled.







Rule


Creating a rule is a multi-step process.


Only one rule applies per listener connection.





priority


In case more than one rules match, the one with the lowest integer value priority applies (0 being the highest priority). Prioritizing rules is required in a number of cases and is used to handle advanced scenarios. 


Make sure that you do not create multiple rules with the same priority, as only one of them will randomly apply.



source


As source we refer to any certain IP or groups of IPs, Geo Groups or Geo Areas, filtering (groups of) listeners etc. that the rule will apply to. In our case we will choose to apply the rule to all the listeners and we choose “Any Source”



target


This is the step where the rule's target is selected. Target could be a single stream, a group of streams (i.e. 30 out of 150 streams operating under an account) or all streams (any target) operating under an account.



action


Here is where an action is configured to apply once stream(s) and rule(s) match.



percentage


Configuration of the percentage of listeners (that match the rule) the action will apply to.



schedule (optional)


Once a rule is created, it will be active immediately (scheduled to always apply) or can be scheduled to apply in certain time frames. Scheduled slots can either refer to day(s) or hour(s) or both. Additionally, there can be combinations of different slots.






Specifically for Triton


Steps to be taken to serve vast ads as preRolls & midRolls: 


  1. On the account level, go to ‘Session Rules’

  2. Go to ‘Content Providers’ and click on ‘Add Provider’

  3. Fill in a provider’s name of your choosing, select as type “RCS TRITON” and add the (preRoll) URL and midRoll URL corresponding to the broadcaster's account in the provider.

    It is mandatory to enable ‘Append Listener Id’ (for Triton this would be passed as lsid), ‘Append Listener Query’, ‘Delay Report’  and ‘Cache Response’ (if needed).




    Listener ID and Query parameters management:

    When ‘Append Listener Id’ & ‘Append Listener Query’ are enabled, Revma is passing through all query parameters. As a result, any parameters that are carried in the Revma Stream URL will also be forwarded when a call to Tap ODAD ad server via the OnDemand API occurs.


    More details can be found here:

    Parameters 

    Listener ID Management 




  4. Go to ‘Actions’ and ‘Add Action’
  5. Create a ‘VAST’ action by selecting “VAST” at the Type dropdown.


    - Leave the Replacement Policy at its DEFAULT state.
    - Click on enable preRoll
    - Select the Provider you have created in the previous steps

  6. Go to ‘Rules’ and ‘Add Rule’

  7. Set ‘Source Type’ as ‘Any Source’

  8. At ‘Target Type’, select ‘Single Stream’

  9. Fill in the station’s name under ‘Stream Filter’ or the station’s stream name under ‘Stream’

  10. Under ‘Action’ select the ‘Vast’ action you previously created.

  11. Leave the Percentage of listeners to apply this action to 100

  12. Click ‘Save Changes’

  • Now a preRoll will be triggered for each listener that enters the stream (given that VAST content is available on the side of the provider)

  • For a midRoll to be triggered in a ‘Streaming only/ No Playout’ type of station, Revma will need to receive a relevant trigger from the broadcaster's end.



Handling


When Revma receives a metadata update it expects it to be in the following format:
Artist - Title


It will then try to split the string using “ - “ (whitespace, dash, whitespace) as the delimiter. Whatever is left of the delimiter is considered to be the artist and whatever is right is considered to be the title. These extracted fields will also show up on our track reports (in the Revma Portal, under station management) in the corresponding columns.


Delivery


The metadata end up being delivered in-band to streaming clients that support it. If a player supports in-band metadata it will add that information on the first request towards the streaming server. The server will notice this and will inform the player how often it should expect metadata updates. The player then knows which data in the stream are the audio and which are the metadata.


Example request for metadata update:





Method 1


In the “song” query parameter one should specify:

  • text=”Spot Block“ (starts the spot block)

  • text=“Spot Block End“ (Ends the spot block)

Both the Spot Block and Spot Block End queries need to be triggered

For the start of the spot block, the anticipated duration of the spot block needs to be specified. For instance:

  • length="00:02:19" (hh:MM:SS)

In the following example a spot block will be triggered with duration=00:02:19

Example request for ad replacement (spot block end) via metadata update:



Method 2

In the “song” query parameter one should specify:

  • "ADBREAK_LENGTH_duration" (duration in ms)

  • “ADBREAK_END”


Both the ADBREAK_LENGTH_duration and "ADBREAK_END" queries need to be triggered.



For the start of the spot block, the anticipated duration of the spot block needs to be specified. For instance:



Replace {stream} with the station's mountpoint.



















Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article