I figured out that there's always latency of about two to three seconds when sending messages through the Bot Connector of Microsoft's Bot Framework independent of which channel type I'm using.
This means if I call the POST .../messages API method of my Bot directly (so not going through the Bot Connector) I get an answer within several dozens ms. However, if messages are routed through bot connector (e.g. when I use Direct Line communication or Telegram or any other supported channel) it always takes about two to three seconds until I get an answer.
For a possible user this would not be a good user experience so that I'm wondering whether either I'm doing someting wrong (e.g. Bot Connector settings) or whether this is a general problem and will be improved at a later pont of time.
Thanks a lot in advance.
This is a known issue. The BotFramework is still in Preview, so it has yet to be optimized. Expect to see significant performance improvements in the near future.
Related
We're building a video chatroom experience using OpenTok and while we have the fundamentals working, I'm finding that the noise floor is super high when we have many participants in the room publishing audio. Off-browser solutions like Zoom do not seem to have this high level of "white noise", but we seem to still be able to hear each participant immediately.
A secondary problem we're attempting to solve is that of the sheer number of subscriptions required: we're capped by OpenTok's limit of 3000 subscriptions per room. Currently, every client subscribes to every publisher's feed.
While experimenting with different approaches, it occurred to me that this is something all video chat applications would have to solve. Is there an optimal way to approach this currently? I can see the following solutions:
Mute the stream on the publisher side, essentially streaming silence until our voice activity detection (VAD) algorithm triggers.
Mute the stream on the subscriber side until VAD triggers. Because VAD is done on the publisher side, we risk losing the start of their audio.
Only subscribe to streams when VAD triggers. This is like the previous solution, but helps reduce our subscription count. However, I believe the latency and non-determinism here (each client would be individually subscribing, and this likely will be faster for some clients than others) would mean we'd certainly lose the start of speech.
What's the best way to approach this currently with WebRTC? We're targeting Chrome, Firefox, and Safari.
OpenTok Developer Advocate here.
What timing... I literally just wrote a blog post about this: Best Practices for Multi-Party Video Conferencing with the Vonage Video API
I think it covers most, if not all, your questions. Also, be sure to join the Vonage Community Slack where our entire team & community can help.
A one place solution to your problem is OBS,( https://obsproject.com/ ) I guess you know it.
If you dont or if you have used it less, I would like to tell you that, it has immense feature if you explore it correctly and i feel that It will solve your need.
Do use and let me know if your problem is solved, or comment if its not solved.
Hello we are a small team looking to implement a Gupshup/Whatsapp bot.
We are wondering how long does it take for this kind of bot to setup and have in working order?
apologies if is not a technichal question, but we are not sure where else to ask.
You can ask Gupshup directly and they will be able to help better. From WhatsApp's perspective, once you create your account on Facebook Business Manager and add your WhatsApp number, it goes through an account review which typically takes around 2-3 days and once that is approved, you can start sending messages right away. However, some of these businesses like Gupshup have sandbox experiences at times that give you this experience within minutes without having to go through the entire flow.
There are two parts to the implementation. One is business registration with Whatsapp linked with vendor like Gupshup and the other is coding implementation.
These both can be achieved anywhere from one to two months depending on the use case.
I'm working on a project in the Google Cloud App Engine (node.js flexible runtime) and while I've had a pretty good experience with it thus far, I've recently ran into a problem where the engine will sometimes not respond a specific pubsub notification. Sometimes, the results will appear after a few minutes, but often times it requires me to redeploy the app and lose any messages that I had queued up prior. Interestingly enough, when I send a pubsub message through a different subscription, the engine responds to it well. The backlogged messages are then handled, but sending the problematic message again will still not work.
I'm not really sure how to solve this issue. There is no evidence that google received the message from pubsub in the logs. Additionally, waiting for this long will have negative impacts on the project overall, implying that the messages will reach the end destination given enough time.
I'm willing to provide more information to help reproduce the error.
Thanks in advance
Edit The issue has increased significantly in severity. Please see the updated post I made to see the current extent of the issue.
While researching Azure Notification Hubs, I saw there are two Telemetry options available (source):
"Limited"
"Rich"
Although I have found very limited descriptions on the Pricing and the FAQ pages, this is not enough information to make a decision whether I want the "Rich" telemetry or if the "Limited" Telemetry is enough. Additionaly, those descriptions only talk about the "Rich" option:
Standard namespaces have access to Per Message Telemetry and Push Notification Services Feedback
Rich telemetry: You can use Notification Hubs Per Message Telemetry to track any push requests and Platform Notification System Feedback for debugging.
Also, a Tweet asking #AzureSupport for help only lead to the FAQ page and eventually led them to ask me if I could ask this very question on SO.
The only option available next to asking here is to actually try out, but that would incur a monthly fee and extra effort.
The main difference between the two is that "limited" gives you access to counts of various events: registrations, sends etc; pretty much everything you see as graphs in Azure Portal on Notification Hubs blades.
"Rich" (or Per Message Telemetry) gives you access to detailed information about every single push: things like feedback from PNS and many other things. You can think about it as if you were to send requests directly to PNS yourself and log pretty much any meaningful information about those.
Let me know in the comments if I can clarify.
I finally found a useful MSDN page, which has some answers to what telemetry is provided, how, and to who. It says "This API is only available for Standard tier notification hubs" which means Rich Telemetry only, not Limited.
If the PNS platform involved supports it, then Success means it was delivered to the device. Oddly, despite copious other error codes, there seems to be none for "accepted by PNS, but still not/failed to deliver to device."
It provides counts of outcomes, so if you want per-device results, you'll have to send to only to one device at a time.
I have experienced significant variability when using the Instagram Subscription API. For the most part, the API will not post updates to my end-point as specified during the subscribe initiation. My understanding is that the subscription is configured correctly as any of the updates from my personal account are received.
There seem to be reports across the web talking about significant delays. However, it is my experience that accounts that work do so within seconds but in most instances no subscription messages are never received.
There was discussion on the web also regarding queuing of updates sent through to the subscribe API. Which may make a little sense, however a queue would suggest that updates would be received eventually.
I have requested basic permissions, which is sufficient to request public media from each registered account. Yet, there I have a gut feeling that these permissions could be the problem, so I have started the process of requesting public_content.
At this stage there seems to be a number of developers experiencing similar issues, yet no resolutions.
Has anybody been able to resolve this issue?
I'm subscribed to aspect=media object=user and experiencing a similar issue.
For some users, I'm notified 95% of the time. For other users, I've never been notified of a single post.
In this post nithinisreddy mentions that the data is being "sampled". I think this is the reason. Hopefully it improves after the tags/locations subscriptions are deprecated.