I've seen the sample app on github. There is an explicit "Start Broadcasting" button that does what it sounds like (starts broadcasting rtmp).
I'd like not to have an explicit button. I'd like to start broadcasting when the first user in a session publishes his or her camera. So if 5 users connect to the session, call broadcast when the first of them publishes a stream, but not when any of the others do.
Can I query the session and know whether it is live streaming currently? What is the best practice here? Thanks.
TokBox Developer Evangelist here.
You cannot query the number of active streams in a Session, you would have to store that information on your own as events are being dispatched. Please see this SO answer for more details: #OpenTok how enumerate streams in a session?
As for broadcasting, you can start broadcasting programmatically when the first person starts publishing instead of using a visual component to trigger the call. For example, on the client side, you can listen for the streamCreated event and then send a request to your application server to start the broadcast. Your application server would then have to make a the startBroadcast call to OpenTok via a Server SDK or using the REST API.
Alternatively, you could use Session Monitoring to listen to Stream and Connection events on the server via a webhook, to start the broadcast.
To find out more on how OpenTok Broadcasting works, I recommend checking out the following resources:
OpenTok Broadcasting Developer Guide
OpenTok Broadcasting Webinar
Related
We are controlling the sonos via a small IOT device. This device will be placed at the homes of our customers.
In our home automation system we need to know the playbackstate + volume of the players/groups.
At which polling rate can we ask these parameters ?
We cannot use a cloud server to handle the subscription events.
I tried to put a https webservice in the IOT device with a self signed certificate but this doesn't work.
After I have posted the subscription I get a request in my webservice but the cloud sonos server disconnects immediately.
Probably because of the certificate is self signed - Or can there be another reason ?
Is there another way to recieve status events ?
During discovery In the players Json object there is a key 'websocketUrl'.
The documentation says "The secure WebSocket URL for the device. See Connect for details".
But I cannot find more info about this.
Can this be used ?
At which polling rate can we ask these parameters?
Consider using subscriptions instead of polling. See this answer for more: https://stackoverflow.com/a/60893119/4902948
We cannot use a cloud server to handle the subscription events...
Or can there be another reason?
Is there another way to [receive] status events?
You must host a service that satisfies a set of requirements to receive events. See this answer for more: https://stackoverflow.com/a/57189717/4902948
Also see Details on API credentials and events in New features in versions 11.1, 11.2 (S1), & 12.0 (S2).
Can [the 'websocketUrl'] be used?
This is not publicly available for use.
It would be a lot easier to use the (undocumented but more useful) UPnP APIs. You could simply Subscribe to the UPnP RenderingControl endpoint, then you will get an event every time the volume changes. To find when the track changes, subscribe to AVTransport endpoint.
You can do this with a local server (this is how every Sonos app works after all) and no special cert requirements either.
UPnP events are described in the UPnP spec.
Your question doesn't provide details about the language you're using, but if the device is powerfull enough to run node, you have a good change with my sonos library.
You can just pull the required information from the device as often as you like. Or use the build-in event subscriptions. If you use the events, it will automatically setup an http listener and automatically subscribe to all the events you're listening for.
Events are instant (as in 50ms-100ms after the event took place on the device).
If you request information it is send directly to the device and the device will respond with the answer. Pulling multiple data points per second has never been a problem to me.
Warning as stated above, this uses the undocumented local UPNP api, but since their own app also uses it, I'm guessing that won't change soon.
For some security reasons that I can't have a public accessible server to receive data from slack.
So, this is what I'm planning to do:
Inbound message from slack: using RTM API
Outbound message to slack: using RTM API or Web API
Questions:
Any better alternatives?
Any restrictions? (AFAIK, buttons and drop downs can't work)
If Web API reach rate limit, can I use incoming webhook as a backup plan?
RTM only approach
Yes, that would work. With only the RTM API you are limited to:
receiving and responding to messages
Other RTM events.
You can't use any interactive functionality like:
Interactive components (buttons, menus, datepickers)
Dialogs
Rate limit on message posting
Using the webhook as "backup" to circumvent the rate limit is not an option, since the rate limit of posting max 1 message per second applies to all form of message posting.
From the documentation:
In general, apps may post no more than one message per second per
channel, whether a message is posted via chat.postMessage, an incoming
webhook, or one of the many other ways to send messages in to Slack.
Alternatives
You did not give any details about the reasons why your app can't expose an endpoint to the public Internet. But you might want to consider using a VPN tunnel like ngrok.
Yes! Socket Mode
There is a new alternative from slack, Socket Mode, which doesn't require a publicly accessible server.
Note: this is only for private apps.
With Socket Mode you have an API token and your server uses it to communicate with Slack's servers and create a two way socket connection. This means your Slack Bot's code can run on a machine behind a firewall and not require any inbound ports to be opened.
Slack message delivery requires an acknowledgement once you get the message, or else they may retry to deliver it.
Limitations
Socket Mode has two main limitations:
Apps using Socket Mode are not currently allowed in the public Slack App Directory.
Socket Mode is only available for apps using new, granular permissions. If you created your app on or after December of 2019, good news: your app already uses the new permissions. Otherwise, you may have to migrate your classic Slack app to use granular permissions before turning on Socket Mode.
I'm new to software development in general, and I'm writing a backend for a simple ride-sharing iOS application (which I'll develop later). I'm using Vapor to create the backend.
When a user makes a trip request to the API, I want to create a new trip and establish a websocket session between the user and a driver. The problem I'm having is how can I notify a driver that a request is in and add him to the session?
Here's what I've come up with so far, although I'm not sure if it's going to work:
When a trip request comes in, I would create a session and a trip object with the session id. When a driver visits the "Trip requests" tab in the app he would make a get request to retrieve active trip requests. When he then clicks on one of the trip requests, he would make a request with the session id of that particular trip to be added to that session.
The problems I'm seeing with the above solution is that that would make the User the Poster, and the Driver the Observer, which I'm not sure is the way to go since I want the driver to act as a poster (to send location updates so that the user can track the driver on the map in real time).
Another problem is that users would have to wait indefinitely before a driver accepts their request.
Is there a better way to notify the driver of a trip request? How can I go about achieving this?
First, you will get trouble when trying to establish a direct connection between user and driver, because it's quite difficult to directly connect to an app on a smartphone (changing IPs, NAT, firewalls and opening ports are some of the problems).
I'd suggest, you implement some kind of REST API for the trips/trip requests. To notify the driver or send updates back to the user, you can either use push notifications (for iOS it's APNS) or websockets. In the best case both for different situations.
Here are some hints for further research on those topics:
WebSockets: In Vapor, an example chat app using websockets , WebSocket wrapper for Vapor
Push notifications: Gorush, push notification server, Apple Notifications, (WIP: APNS on NIO)
I hope that helps for your next steps. Your question is quite broad to be more specific.
I want to get all publisher or subscriber or stream object from a session object, Is it possible?
TokBox Developer Evangelist here.
As Fran mentioned, there is no API that exposes all of the streams in a session so you would have to store that data locally. You can do this by listening to the streamCreated and streamDestroyed events on the client side or by using the session monitoring feature on the server side. Session monitoring allows you to receive the following events via a webhook:
connectionCreated
connectionDestroyed
streamCreated
streamDestroyed
Right now there is no API to retrieve publishers or subscribers data. You can get session information and streams:
https://tokbox.com/developer/rest/#get-stream-info
We are currently implementing a simple chat app that allows users to create conversations and exchange messages.
Our basic setup involves AngularJS on the front-end and SignalR hub on the back end. It works like this:
Client app opens a Websockets connection to our real-time service (based on SignalR) and subscribes to chat updates
User starts sending messages. For each new message, client app calls HTTP API to send it
The API stores the message in the database and notifies our real-time service that there is a new message
Real-time service pushes the message via Websockets to subscribed Clients
However, we noticed that opening up so many HTTP connections for each new message may not be a good idea, so we were wondering if Websockets should be used to both send and receive messages?
The new setup would look like this:
Client app opens a Websockets connection with real-time service
User starts sending messages. Client app pushes the messages to real-time service using Websockets
Real-time service picks up the message, notifies our persistence service it needs to be stored, then delivers the message to other subscribed Clients
Persistence service stores the message
Which of these options is more typical when setting up an efficient and performant chat system? Thanks!
You don't need a different http or Web API to persist message. Persist it in the hub method that is broadcasting the message. You can use async methods in the hub, create async tasks to save the message.
Using a different persistence API then calling signalr to broadcase isn't efficient, and why dublicate all the efforts?