The SIRI Repeater Application

The SIRI repeater application is a command-line application that provides a repeater/proxy between existing SIRI data sources and other SIRI clients. The repeater serves to provide:

  • reduction on the load of your primary SIRI data source
  • customizable data filtering and transforming
  • additional client authentication and management

The app is still under active development as we work to flesh out these features.

The general idea is that the repeater application connects to your existing SIRI data sources as a client and also provides a server to rebroadcast SIRI data to other clients.

In the this documentation, we'll often refer to PRIVATE SIRI sources, which are the SIRI data sources you wish to proxy, and PUBLIC SIRI clients, which will be proxied by the application.

Getting the Application

You can download the latest application here:

Note that we also provide an RPM package of the application as well.

Using the Application

You'll need a Java 1.6 runtime installed to run the client. To run the client:

java -jar onebusaway-siri-repeater-cli.jar [-args] request [request ...]


  • -id userId : specify the SIRI client user id
  • -repeaterUrl url : the url your repeater applications binds to and shares for incoming public client requests (default=http://localhost:8080/)
  • -privateRepeaterUrl url : optionally set an alternate repeater url for binding, but still report -repeaterUrl to connected clients
  • -clientUrl url : the url your repeater application binds to and shares for for private server requests (default=http://localhost:8081/)
  • -privateClientUrl url : optionally set an alternate client url for binding, but still report -clientUrl to connected clients will actually bind to, if specified (default=repeaterUrl)
  • -requestorConsumerAddressDefault : set a default consumer address for a particular requestor, used when an address is not included in a subscription request. Argument should take the form requestorRef=address.
  • -logRawXml path : If specified, indicates the raw SIRI request and response XML should be logged to the console. Valid values are "NONE" (the default), "DATA", "CONTROL", and "ALL".
  • -filter filterSpec : specify a filter to be applied to SIRI data passing through the repeater. See the Filters section below for more details.

Request Spec

Each request command line argument indicates a private SIRI data source to connect to. The request has the following syntax:


At minimum, you need to specify a Url that indicates the SIRI resource to connect to, and a ModuleType that indicates the SIRI module type to request. Additional keys specific to the module type can be used to further filter the request. For example:


For more details, see the full command-line request spec documentation.

Repeater and Client Urls

There are two types of urls you might specify to the repeater application:

  • repeater url - the url the application will listen to for incoming public client connections (default=http://localhost:8080/)
  • client url - the url the application will use for publish/subscribe communication with private SIRI data sources (default=http://localhost:8081/)

There may be situations, as determined by your network/firewall/NAT configuration, that require a different public url that external clients will try to connect to and a private url that the application will actually bind to (with your firewall connecting the dots).

For example, your public url for incoming client requests might be while internally you want the SIRI repeater application to listen at http://localhost:8080, with port-forwarding linking the two. In such a case, you'd specify -clientUrl and -privateClientUrl http://localhost:8080.


Filters provide functionality to modify and transform data as it passes through the repeater. Filters can be conditionally applied and chained to provide powerful data customization. There are two primary pieces to a filter: matching rules to determine when a filter is applied and the filter itself. We cover both pieces in the following sections.


Consider the scenario where we have an incoming SIRI Vehicle Monitoring data stream coming from an internal AVL system. We wish to share that data with external developers, but we first want to remove sensitive data from the stream, such as operator ids. We could specify the following filter:

-filter Match.ModuleType=VEHICLE_MONITORING,Match.RequestorRef=JoeUser,Filter.Type=Elements,

This filter specification can be described in terms of its specific arguments:

  • Match.ModuleType=VEHICLE_MONITORING - Apply the filter to vehicle monitoring data.
  • Match.RequestorRef=JoeUser - Match requests where the RequestorRef equals "JoeUser".
  • Filter.Type=Elements - Specify the filter type to be a "Elements" filter, useful for modifying specific elements of the SIRI data.
  • Filter.Element.VehicleActivity.MonitoredVehicleJourney.OperatorRef - Specify that the "VehicleActivity.MonitoredVehicleJourney.OperatorRef" subelement of the Vehicle Monitoring delivery should be cleared.

For complete details on matching and filter rules, see the following sections.

Matching Rules

Matching rules determine when a filter is applied to a particular pub/sub data stream. Right now, we support a simple matching syntax that allows you to match the parameters of a subscription. You can specify any or all these m

  • Match.ModuleType=match_spec - The SIRI module type (eg. VEHICLE_MONITORING, SITUATION_EXCHANGE, etc.) - see module types for full list
  • Match.Address=match_spec - Match a Siri.SubscriptionRequest.Address value
  • Match.ConsumerAddress=match_spec - Match a Siri.SubscriptionRequest.ConsumerAddress value
  • Match.SubscriptionFilterIdentifier=match_spec - Match a Siri.SubscriptionRequest.SubscriptionFilterIdentifier value
  • Match.RequestorRef=match_spec - Match a Siri.SubscriptionRequest.RequestorRef value
  • Match.MessageIdentifier=match_spec - Match a Siri.SubscriptionRequest.MessageIdentifier value

Each matching rule includes a match_spec that determines how the target value will be matched. We support the following matchers:

  • value - Match a value directly
  • StartsWith(...) - Match a value that starts with the specified prefix.
  • EndsWith(...) - Match a value that ends with the specified suffix.
  • Regex(...) - Match a value using a regex.
  • Empty() - Match an empty value, where an element is not present or has no value.

Filter Rules

We support some built-in filter functionality. If you are looking to implement your own filter functionality beyond what is possible out-of-the-box, see the next section. Right now, we support one simple element-based filtering modeling out-of-the-box. To use this filter, simply specify:

  • Filter.Type=Elements

You can then specify multiple Filter.Element.XXX=YYY rules, where XXX is an XML element expression path and YYY is the filter value for any matching elements. Note that the path is specified RELATIVE to the module delivery sub-element, not the root SIRI/ element. For example, if you specified a Match.ModuleType=VEHICLE_MONITORING, your filter will be operating relative to a VehicleMonitoringDelivery/ elements. Thus, if we want to filter the OperatorRef/ out of the data stream, we'd specify:

  • Filter.Element.VehicleActivity.MonitoredVehicleJourney.OperatorRef

Note that we will filter ALL matching sub-elements. That is, a particular ServiceDelivery/ might contain multiple VehicleMonitoringDelivery/ elements, which might contain multiple VehicleActivity/ elements. We'll filter all of these matching elements. In terms of the actually element value, we clear the value by default. You can optionally specify a NEW value using the following syntax:

  • Filter.Element.VehicleActivity.MonitoredVehicleJourney.OperatorRef=some value

Custom Filters

If you need more complex filter behavior, you can additionally specify and implement your own filter. The repeater application is written in Java, which means you can easily implement your own filter and add it to the application.

The key interface to implement for a filter is org.onebusaway.siri.core.filters.SiriModuleDeliveryFilter. The interface looks like:

public interface SiriModuleDeliveryFilter {

  public AbstractServiceDeliveryStructure filter(ServiceDelivery delivery, AbstractServiceDeliveryStructure moduleDelivery);


Recall that a SIRI service delivery payload typically looks like:


We have a parent <ServiceDelivery/> element wrapping module-specific delivery elements. The filter interface operates on these module-specific delivery elements. Specifically, the filter takes the parent <ServiceDelivery/> element and the module-specific delivery element as argument and returns a filtered module delivery element, or null if the element should be filtered out completely. Your filter implementation can simply return the input module delivery object, perhaps modified in some way. It can also return an entirely new module delivery object or null to indicate no result should be published to the client.

To create filter class of your own, you'll need to add the onebusaway-siri-repeater-cli.jar to your developer classpath so that Java can find the definition for SiriModuleDeliveryFilter.

To include your custom filter, use the Filter.Class parameter to specify the full class name of your filter.

-filter Filter.Class=package.FilterClassName,...

The class files for your custom filter will also need to be included in the Java classpath when running the application.

RPM + Linux Service

We also provide an RPM package of of the onebusaway-siri-repeater-cli SIRI repeater application. The package should make it easy to deploy the repeater as a service on a Linux server.

Downloading the RPM

You can download the latest RPM here:

Note: For complicated reasons, we offer a ZIP file download containing the RPM. Extract the ZIP to get at the rpm inside.

Installing the RPM

Install the RPM like you would any other:

rpm -i onebusaway-siri-repeater-VERSION.noarch.rpm

Note that you typically need to be root to install an RPM.

Configuring the Repeater

The primary configuration file for the repeater is:


The file will contain a couple of options by default. The one you are most concerned with is REPEATER_ARGS:

# Custom onebusaway-siri-repeater arguments go here

REPEATER_ARGS accepts the same command-line arguments as the stand-alone onebusaway-siri-repeater-cli application. As a quick example, the following config sets the requestor ref to me and subscribes to vehicle monitoring messages from http://host:8080/subscribe.xml:

# Custom onebusaway-siri-repeater arguments go here
REPEATER_ARGS="-id me Url=http://host:8080/subscribe.xml,ModuleType=VEHICLE_MONITORING"

Starting and Stopping the Service

You can use standard init.d scripts to start and stop the onebusaway-siri-repeater daemon:

/etc/init.d/onebusaway-siri-repeater {start|stop|restart|status}

You can also use the built-in service command to start and stop the service as well:

service onebusaway-siri-repeater {start|stop|restart|status}

You can also control how the service is started on boot using the chkconfig command.


By default, the onebusaway-siri-repeater daemon logs to the following location: