Skip to main content

Non-unique Source IDs and JavaTV Service objects

1 reply [Last post]
Joined: 2008-12-18

Here's a document I've written up describing the issues the RI team
has seen testing on multi-SourceID networks - and some recommendations.
Please post any thoughts/experiences below.

Non-unique Source IDs and JavaTV Service objects

A number of cable networks have multiple Source IDs
mapped to distinct programs on the network.

For example, the SCTE-65 Virtual Channel Map tables on a network
may signal three distinct programs with the same SourceID -
perhaps containing the same channel in different formats: analog,
SD, and HD. These three programs are then represented as JavaTV
Service/ServiceDetails objects - retrieved via
SIManager.filterServices() or

ECN-1186 introduced the following language into OCAP 1.0.2/1.1 to
clarify stack behavior on multi-Source ID networks: Non-unique Source Ids

Source IDs are considered unique by APIs that use source ID
based locators to look up services, e.g., JavaTV. However,
there are no network requirements for source IDs to be unique
in a signaled VCT. In the event more than one service is
signaled with the same source ID, the following implementation
behaviors are defined:

  • When multiple services are signaled with the same
    source ID, the implementation SHALL include all of those
    services in the JavaTV SI database.
  • When any method is called and passes a parameter that
    contains a source ID term, e.g.,
    SIManager.getService(Locator), []), and the source ID
    term identifies multiple services that are signaled
    simultaneously, the implementation SHALL use the
    identified service that was encountered first in the
  • When the SIManager.filterServices(ServiceFilter)
    method is called, the implementation SHALL apply all
    services to the filter parameter, including those with
    identical source ID based locators. When the parameter
    is null, the implementation SHALL return all services,
    including those with identical source ID based locators.
  • When the method is
    called, the implementation SHALL select the signaled
    service associated with the Service parameter.

And the following language has been carried through from
OCAP 1.0 to OCAP 1.1.3: OCAP Implementation Constructors for
OCAP Service Locators

When an application calls, the OCAP implementation
SHALL construct the OCAPLocator as follows:

  1. For services that have been created from a frequency /
    program_number pair, or "oobfdc" / program_number pair,
    as described in Section, one of the
    OcapLocator constructors taking a frequency parameter is
    used. This rule applies even in the case that the
    source_id can be identified from the virtual channel
  2. For services that have been created by any other
    means, one of the OcapLocator constructors taking a
    sourceID parameter is used. For a broadcast service, the
    sourceID is the 16-bit source_id provided in the
    signaling for the service. For an abstract service, the
    sourceID is the 24-bit service_id that identifies the


  1. The "OCAP Service Locator" (OCAPLocator for a Service) as
    currently defined in does not uniquely
    identify a broadcast Service.
    • ServiceA.equals(SIManager.getService(ServiceA.getLocator())
      may return false on multi-SourceID networks (SIManager.getService(ServiceA.getLocator())
      may return an entirely different Service object)
  2. Applications which utilize SourceID-based (either Service- or
    ServiceComponent-level) to identify a channel cannot expect
    predictable results from an OCAP implementation - especially
    across STB reboots. In particular, applications should not use
    any of the following APIs/objects with SourceID Locators if
    they wish to operate on multi-SourceID networks:
    1. [])
    2., SIRequestor)
    3.,Locator)/.select(Locator)/.select(Locator [])
    6., Locator)/.retrieveInBand(SIRequestor, Locator)
    7., Locator)/.retrieveInBand(SIRequestor, Locator)
    8.[], ...)
  3. Applications cannot create their own object implementing the interface and expect to get
    predictable results from an OCAP implementation -
    especially across STB reboots.
    • e.g. An application which provides an object implementing Service.getLocator() returning a SourceID Locator may end up recording incorrect content.
  4. OCAP implementations cannot return SourceID-based Locators
    from functions when the application provided a (f,p,m) Locator
    to initiate the activity. In other words, the implementation
    must return a (f,p,m) Locator for activities initiated via
    (f,p,m) Locator (or Returning a
    SourceID-based Locator in these situations may cause the
    application to retrieve a different Service entity than the
    application intended on multi-SourceID networks. The only
    exception to this rule is SPI-mapped Services. The
    implementation must expose SourceID-based Locators to these
    Services in order to enable Service remapping by
    SPI-registered SelectionProviders.
    • e.g.,
      OcapLocator, boolean, ElementaryStream[],
      MediaPresentationEvaluationTrigger) cannot be invoked by the
      implementation with a sourceID-based OcapLocator, since the
      application may inadvertently resolve the
      implementation-provided Locator to a different Service than is
      being authorized.
    • The following methods would be affected by this rule:


      12. org.dvb.dsmcc.ServiceDomain.getLocator()
  5. Any entity wishing to persist or communicate a Service
    reference cannot utilize a Service Locator to do so.
    • e.g. OCAP implementations of RecordingManager cannot use
      Service.getLocator() to save a Service reference. Doing so
      may result in the wrong program (or wrong format) being
      recorded by the implementation. Instead a variety of fields
      must be saved in an attempt to uniquely identify the Service
      in the case of a reboot. The RI is now utilizing a
      (source_ID,virtual_channel_number) tuple to rebind the
      ServiceRecordingSpec reference after a reboot in order to
      avoid recording incorrect content.
    • e.g. Sending a Service Locator into persistent storage or
      to another endpoint - via HN metadata or other means - could
      result in the wrong content being
  6. Applications should utilize methods which take Service
    references whenever possible - pass Service object references
    retrieved via In
    particular Applications should utilize:
      (instead of select(Locator []))
    2. (instead of
  7. When possible, applications should use (f,p,m) Locators to
    identify Services/ServiceComponents if/when Locators are
    • e.g. ocap://f=0x15476340.2.m=0x08
    • e.g. ocap://f=0x15476340.2.m=0x08.0x81,spa
  8. There needs to be a mechanism provided to allow Applications
    to resolve Services to non-SourceID (e.g. (f,p,m)) Locators.
    • OCAP's Service.getLocator() contract could be changed (
    • ServiceDetails.getLocator() could return a non-SourceID
    • When called with a SourceID Locator,
      locator, SIRequestor requestor) could be required to
      retrieve ServiceDetails objects corresponding to all
      Services signaled with that SourceID.
  9. A true OCAP Service Locator should be considered for the
    specification. This would allow Locator-based methods to be
    used safely and would enable Service references to be
    persisted and communicated unambiguously.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-12-18

See IT-281 (Start recording performance degradation) for one manifestation of this issue.