Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Do players call the BSN.cloud server regularly to get new or updated scheduled content?

 Expand

All connected and healthy players establish and keep persistent WebSocket connections with bsn.Content. If a player has "BSN" setup type and an active subscription, it will receive events from the server when either its settings or schedule are changed by any user in BrightAuthor:connected. The event propagation should take not more than few minutes (typically one minute), and the player requests the new settings or schedule immediately after receiving such an event.

Note that changes in Dynamic Playlists, Tagged Playlists, Live Data Feeds and Live Media Feeds are propagated differently. Each of these entities has an underlying mRSS feed and after retrieving them from the presentation, a player checks for changes in each feed separately with a frequency defined by the TTL property of Tagged Playlists and Live Media Feeds in BrightAuthor:connected.

Do the logs show when there has been a successful sync with the cloud?

 Expand

You can look for the sync.checkforcontent.request message received entries in the player's system log (available via the RDWS) to monitor these events. If the player is disconnected and/or does not accept messages, the server repeats them multiple times with decreasing frequency and eventually stops. The player also checks for missed settings and schedule updates every six hours and retries if it cannot reach bsn.Content, and requests settings and schedule from the server after each reboot.

What are the sources for inbound BSN.cloud flows?

 Expand

BrightSign does not initiate any contact with BrightAuthor:connected or players. Users initiate connections, send requests, or subscribe to events, and the server replies. There are no cases when a server sends a request to a player, which would be impossible in most cases anyway since players are behind firewalls/gateways.

How can we identify HTTP calls on port 80 from the middleware vs. calls from elsewhere?

 Expand

Only two server endpoints listen on TCP port 80 and do not require transport-level encryption (as described on this page):

  • time.brightsignnetwork.com

  • services.brightsignnetwork.com

The first is an NTP server and has other endpoints as well, and the second is used only to check the connection with the cloud at the early stages of the BOS boot. In both cases, it is impossible to use TLS because the handshake and certificate validation are possible only when boot is finished and the player's clock is initialized correctly.

  • No labels