I'm using OpenTok Web Client SDK and OpenTok .NET Server SDK to generate TokBox sessions that are always going to be multiparty conferences with video being published by many.
I'd like to limit the number of streams that can be published and somehow set that as a session property. Right now I know this value - the number of current publishers - in the client side, and I can of course prevent a new user to publish, but I'm running into this scenario where two users try to publish at the same time, and both are accepted. Ideally the user who published the very first of the two should be accepted, so I'm wondering if there is a way to set this property in the TokBox "server side", as a session property, so the server would reject a new publisher if max. reached.
Please notice that I don't have any server state on my own that keeps track of the created sessions nor how many publishers they have, etc.
Thanks!
Adam here from the OpenTok team.
There is no server-side setting available in OpenTok to limit the number of streams allowed. You could do something like I suggest in this answer though. Where you keep track of streamCreated Events and look at the creationTime property and if your stream is the n-th then you unpublish. Or you can forceUnpublish the n-th stream.
Related
I have just started using Agora.io and want to implement it to a project of mine.
Following some tutorials I can already start a streaming as host, and other user can join to it as long as the stream is published.
My problem is I would like to show the join button only when the stream is published and not all the time. Also I will have dynamic channels in the future so Iam looking for a way to get the list of all active channels. How can I do that?
you can use this Restful API to get all the active channels: https://docs.agora.io/en/Interactive%20Broadcast/dashboard_restful_live?platform=All%20Platforms#get-the-project-list-get
When there is at least one user in the channel, the channel is considered as an active channel.
In my current project I am using the Kreait Firebase PHP SDK to send out push notifications to Android & iOS devices that have subscribed to notifications on named topics. No issues thus far. However, rather than have fixed topic names I would now like to generate topic names based on the current "condition" of the connecting device. The condition could, for example, be a geographic location.
This is not too difficult either and I have modified my app to handle this. However, in order to put the ability to have such autogenerated topics to use I need to know the topic names on my server so I can send out targeted messages via Kreait. I find Google's Firebase documentation a bit dense at times and have not been able to establish whether it is possible to assign webhooks that get called by Firebase whenever a SubscribeToTopic, UnsubscribeFromTopic event occurs.
A simple question - does FCM even offer anything like this capability? If so, any pointers to the relevant documentation would be much appreciated.
There is no public API to get a list of topic names from Firebase, nor is there a way to hook into the subscription mechanism.
Your best bet is to simply make two calls when a user subscribes to a topic: one to Firebase, and one to your own backend API that keeps a list of active topics/conditions.
Given a session ID or for the last 10 sessions the Inspector tool provides interesting metrics regarding bitrate, packetloss and latency. Is there an existing API or a way in which we can download this information for each session ID?
Also would it be possible to fetch information of the sessions which are not the recent 10 via an API? If there's no API, is there a way I can log this information from each of the ClientEvent or ClientQos network requests to a database?
I am still learning Tokbox API.
Currently, inspector is limited to 10 last sessions, and I never came across a method to call inspector using Tokbox API. Therefore, the best thing is to log the information by yourself.
In GitHub example [https://github.com/opentok/opentok-network-test], Tokbox has mentioned that using network stat API information regarding the packet drops and audio/ video framerates can be fetched if you are using Tokbox media router.
Tokbox js developer reference has the same information, which I copy pasted below.
https://tokbox.com/developer/sdks/js/reference/Subscriber.html#getStats
getStats(completionHandler)
Returns the details on the subscriber
stream quality, including the following:
• Total audio and video packets lost
• Total audio and video packets received
• Total audio and video bytes received
• Current video frame rate
You should be able to save periodically the stats received by calling getStats() method to a database.
I will publish an example, based on my free time.
With the introduction of topics in android gcm I was evaluating this option to easen the work that should be done to mantain in sync our server with some subscriptions.
However I have read in the documentation that the use of topics is limited to 1 million subscriptions. Does this mean that you can't have more than one million users (with one or more topics) or that you can only have 1 million topics subscribed (for example 100.000 users subscribed to 10 topics each) ?
It's a limit on subscriptions in your app in total, across all topics created within your app.
You will get a TOO_MANY_SUBSCRIBERS error when the number of subscriptions per app exceeds the 1 million limit.
I think the limit has now been scrapped:
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app.
https://developers.google.com/cloud-messaging/topic-messaging
You could try to work around this limit by using multiple SENDER_IDs when registering devices.
Since the 1 million subscriptions limit is enforced application-wide, I'm pretty sure that Google's way of tracking that is via the SENDER_ID.
And then, on the server-side, you'd have to issue multiple publish requests to GCM (each time with a different Server API Key, to support more than 1 million devices).
I'm going to test this theory out and let you know what I find. The worst-case scenario is that it is enforced via the application's package name (com.example.package), and then there is no elegant workaround.
Update: The limit has now been removed!
We’re now happy to announce that we’re allowing unlimited free topics for your app. This means app developers can place an unlimited number of devices within each topic and create an unlimited number of topics.
http://googledevelopers.blogspot.co.il/2015/12/google-cloud-messaging-weve-come-long.html?utm_source=Android+Weekly&utm_campaign=1cb848077c-Android_Weekly_184&utm_medium=email&utm_term=0_4eb677ad19-1cb848077c-337844217
GCM now removed the limit, check this: https://developers.google.com/cloud-messaging/topic-messaging
Also Firebase Cloud Messaging (FCM) the same. https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
GCM topic messaging allows your app server to send a message to
multiple devices that have opted in to a particular topic. Based on
the publish/subscribe model, topic messaging supports unlimited
subscriptions per app. The app server sends messages with payloads up
to 2KB to the topic, and GCM handles the message routing and delivers
the message reliably to the right devices. For example, users of a
weather forecasting app could opt in to a "severe weather alerts"
topic and receive notifications of storms threatening specified areas.
Topic messaging supports unlimited topics and subscriptions for each app.
Check This
[FCM Notifications][1]https://firebase.google.com/docs/cloud-messaging/android/topic-messaging
I heard that there are applications that allow people to do transactions by just touching there iPhones to each other. How is that archive via code in Objective C?
I beleive each phone has to detect the "bump" (using UIAccelermeter) and send an immediate notification of the event ot a server (perhaps with a timestamp and some geolocation info too?). Then the server matches up events that occur at the same moment, to determine the two devices involved. Then the server facilitates the transaction by sending each phone's info to the other.
take a look at the Bump API http://bu.mp/api.html as used in the Bump iPhone application. I haven't used it myself so I cannot say how easy it is to integrate but they claim it only requires you to add ten lines of code.
The way I would do it would be to have each device send the other their UID over bluetooth and then have them both send a message containing the other devices UID and their own UID to the server with a timestamp, then have the server handle the transaction.