Darren Schreiber
-
Posts
1,202 -
Joined
-
Days Won
27
Content Type
Profiles
Forums
Resource Library: Monster UI Apps for KAZOO
Events
Downloads
Posts posted by Darren Schreiber
-
-
Also, I've re-confirmed that this appears to be only traffic to NY so far that I've been able to simulate this with. Very strange. I think a peer somewhere is saturated. I wonder if Level3 is having peering disputes again with Verizon and/or Comcast or their backhaul providers.
-
I don't think this is throttling. BlueTel has been working with me on this with some traces. What is super weird is Level3 (or Verizon?) is sending traffic to our gateway IP (.1) via one peering point, but traffic to our other nodes is going through an alternate peering point. I think something is still wrong, and am working on it.
We did confirm that if you're impacted by this, you can reroute to us-central.p.zswitch.net for now and the problem is resolved. I may even do that for the remainder of the day for all traffic until I understand this issue more.
-
10 minutes ago, Karl Stallknecht said:
Ohh right! So then yes, technically functionality was removed lol.
Now we're splitting hairs and finding things to complain about. OK, I'll bite.
This thread is about Account IDs and Auth Tokens in the GUI. If you want to change the topic to the old Developer's app, I again state that the move from Kazoo UI to Monster UI had no change or removal in functionality. That's because the developer's app was replaced over 2 years ago in the Kazoo UI. Considering that this is the first time anyone has brought it up, I'm assuming this functionality was not missed. It wasn't a working product, it was supposed to be a demo, and it was not kept up to date with the latest functionality because it took too much time to do so. Postman was the replacement, as it provides a better experience and is easier to manage. If you have an issue with the Developer App missing, then please start a different thread - don't hijack this one, as it's totally unrelated.
-
Not likely. Seems like you're experiencing congestion frankly on your Comcast link. Especially since your other customers aren't having this issue.
-
Try it from one of your customer/other sites. You'll see it's higher. Although even in what you pasted, that's a high of 42ms, not 50-70ms. But I was 50-70ms going to you when I tested, but again, ONLY to your site. Your customer sites (I tested 3) are fine.
-
Also I just checked some of your other customers who are also on TWC, and actually, they get 15-20ms! So seems like it's your site in particular that's having issues. You should definitely go yell at Comcast.
-
Logicwrath, in your case, I looked up your IPs. You have one on Comcast that's all over the map but seems to be an issue on your side, and one via WideOpenWest that seems just fine.
# ping 74.94.X.X
PING 74.94.X.X (74.94.X.X) 56(84) bytes of data.
64 bytes from 74.94.X.X: icmp_seq=1 ttl=58 time=59.6 ms
64 bytes from 74.94.X.X: icmp_seq=2 ttl=58 time=38.0 ms
64 bytes from 74.94.X.X: icmp_seq=3 ttl=58 time=25.3 ms
64 bytes from 74.94.X.X: icmp_seq=4 ttl=58 time=40.7 ms
64 bytes from 74.94.X.X: icmp_seq=5 ttl=58 time=21.0 ms
64 bytes from 74.94.X.X: icmp_seq=6 ttl=58 time=64.3 ms
64 bytes from 74.94.X.X: icmp_seq=7 ttl=58 time=56.4 ms
64 bytes from 74.94.X.X: icmp_seq=8 ttl=58 time=51.8 ms
64 bytes from 74.94.X.X: icmp_seq=9 ttl=58 time=32.0 ms
64 bytes from 74.94.X.X: icmp_seq=10 ttl=58 time=28.9 ms
64 bytes from 74.94.X.X: icmp_seq=11 ttl=58 time=45.9 ms
64 bytes from 74.94.X.X: icmp_seq=12 ttl=58 time=73.0 ms
64 bytes from 74.94.X.X: icmp_seq=13 ttl=58 time=61.9 ms
^C
--- 74.94.X.X ping statistics ---
13 packets transmitted, 13 received, 0% packet loss, time 12016ms
rtt min/avg/max/mdev = 21.041/46.103/73.057/15.879 ms
[root@fs001 ~]# ping 67.149.X.X
PING 67.149.X.X (67.149.X.X) 56(84) bytes of data.
64 bytes from 67.149.X.X: icmp_seq=1 ttl=60 time=17.4 ms
64 bytes from 67.149.X.X: icmp_seq=2 ttl=60 time=16.9 ms
64 bytes from 67.149.X.X: icmp_seq=3 ttl=60 time=16.9 ms
64 bytes from 67.149.X.X: icmp_seq=4 ttl=60 time=16.1 ms
64 bytes from 67.149.X.X: icmp_seq=5 ttl=60 time=20.4 ms
64 bytes from 67.149.X.X: icmp_seq=6 ttl=60 time=18.9 ms
64 bytes from 67.149.X.X: icmp_seq=7 ttl=60 time=15.8 ms
64 bytes from 67.149.X.X: icmp_seq=8 ttl=60 time=17.9 ms
64 bytes from 67.149.X.X: icmp_seq=9 ttl=60 time=17.2 ms
^C
--- 67.149.X.X ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8011ms
rtt min/avg/max/mdev = 15.842/17.543/20.499/1.367 ms
A traceroute to the poor looking route shows that we are at 8.7ms to the handoff point with Comcast in Shelby, MI:
1: no reply
2: ae-7-7.bar1.Detroit1.Level3.net 6.939ms asymm 3
3: Comcast-level3-50G.Detroit1.Level3.net 8.072ms
4: no reply
5: te-5-1-1-cbr02.shelby.mi.michigan.comcast.net 8.764ms
6: no reply
So your issue on that Comcast link has to be something in your region or last-mile. You should contact Comcast about that.
-
Not sure where you're pinging from, but that round-trip is a direct connect via Level3 to Chicago and is looking just fine. There is no issue or slowdown there. So I'd have to see a full traceroute to even comment further.
-
You're talking about something different, FastDevice.
-
We are working on a new doc site, I'll see if we can post some info about the keyboard shortcuts and how they work.
-
Just now, Karl Stallknecht said:
In Kazoo you could just go to the account manager and click the account and it would show you the account ID. I didn't realize that feature was still there in Monster, but it was hidden.
As for the auth token, I was using the developer app to get that. Like @Tuly mentioned most of the time I need to run a super short and simple API command. I found it annoying (even with Postman) to go through the multi-step process to a) figure out the account ID, b) generate a token, and c) then use that token to run the API command, versus just logging into the GUI and copying and pasting the account ID and auth token. Even though the auth token changes, as long as I just go to the GUI and copy and paste the most recent one then it's fine.
Got it. So my point in my reply was that nothing was taken away from Kazoo UI, nor intentionally hidden. All the things available in Kazoo UI are still available in Monster UI, and have infact been enhanced to make it easier (hence the 'd' key to get the data with one push). So hopefully you see this as an improvement. Your original post seemed to imply we took something away that was there before - we did not.
-
Hi guys,
I appreciate all the energy on how to make the provisioner better! We're listening.
Most of what's listed here seems to be bugs, so if they're reproducible, then please file a SEPARATE post with the bug, and we'll investigate it for sure. In the meantime, we're trying to figure out our roadmap, which we do in a separate cycle from bug management. So, I'd like to get back to the "what should we do next" roadmap item, since we want your votes on it! Also, I don't think our team realized our new forums system has voting via polls :-) It's a bit buried in this forum software. So I've asked @Brooke Shepherd and @Chris Kerber to re-post this forum but in poll format. Then you can vote on what you want most! Hopefully that works better.
This thread has gone a bit off topic. I'd like to close it if that's OK and instead have the bug-related stuff posted separately so we can look into it. I know, for example, that the codec items on Yealinks were just discussed in a separate forum post, so it'd be better if we had one forum post per bug so each one can take it's own "life" on (even if you feel there are lots of bugs that have piled up). Thanks in advance, this will help us get through them all.
-
We are working on supporting OAuth and a few other strategies as a baseline. Past that we can open it up for suggestions. Sponsorship is always welcome, as it helps us fund the development of such projects. Feel free to drop a note to sales@2600hz.com for that portion, but you are welcome to continue to post ideas here regardless.
-
That's correct. To support single sign-on features in the future, we moved to JWT-based authentication in 4.0. It also allows us to avoid storing additional information in our database about your authentication mechanism.
Please read https://jwt.io/introduction/ if you would like to understand more about this technology, it is a common web standard now (RFC 7519). While it may seem more complicated it actually paves the way for single sign-on when you link it to your own Monster apps in the future, while also allowing our systems to work better in a distributed manner (less data to sync across nodes), among other things.
-
Thanks, I'll have someone check on the T58V.
-
Thanks, I'll ask @JR^ and @Chris Kerber where they think this should go in the planning & UI.
-
3 hours ago, Karl Stallknecht said:
Wow, thanks @Tuly! I was pulling my hair out trying to find the account ID and generate an auth token now that I can't get it from Kazoo :-P Using the API to get those pieces of information was annoying lol.
What do you mean "now that I can't get it from Kazoo"? The Account ID is available in both the account manager and the currently logged in user's control center, and the auth token was never available in the old Kazoo UI. It's the same as it has always been?
The only thing the debug option allows for is retrieving the auth-token, which has never been exposed previously.
-
LOL this feature was discussed on one of our webinars about a year ago :-)
Press the question mark key on any screen for more tips. You must use keyboard shortcuts only when a text box is not already selected (otherwise it thinks you're typing in the text box).
You just need to push d, not cd, in this case.
-
Yes but most people expect it to also not open the bridge until a moderator arrives, drop callers at the end when a moderator leaves, and give DTMF control, too basically. None of that works (yet).
-
No, I'm quite sure the issue being discussed in this thread is limited to us-east at this point.
-
There was an issue where if you disabled codecs on Yealinks in the provisioner GUI it would remove that setting from the config, which actually left the default on the phone itself, but the expectation would be it would be removed on the phone, too. This issue should now be patched but you'll need to re-save your config file.
Please try it again and see if it works now.
-
Please note that we do not currently support video transcoding. That is one of the reasons we decided to start the Private Cloud initiative. Doing video transcoding on the hosted shared cluster will be tough - the demands are VERY high. So we will start offering video transcoding soon, but it will likely require private cloud servers so that you're not messing up anyone else's equipment when you have video transcoding/muxing going on.
That said, once it's launched, you'll have both video transcoding AND video conferencing.
For now, if you want video:
* Enable ONLY H263 OR H264 on ALL devices, both in the GUI and on the device itself
* START your call in video mode - do not try turning it on mid-call
And it should work (in proxy / no transcoding mode)
-
The media servers in ORD are 8.45.131.x . However there is a packet fragmentation problem in ORD when the packets are sourced from Rackspace servers, so we had temporarily disabled them. We will be restoring them this weekend, so you should start seeing that source IP as of Monday.
-
On 8/24/2017 at 7:33 AM, Logicwrath said:
Everyone, this type of collaboration is going to drastically improve the product. I strongly believe that getting the community involved in the planning and development of new features is critical. I suspect it would be hugely positive if there were more enhancement style threads requesting feedback and/or feature requests for projects in development. Give the end users and re-sellers the ability to point out what is most important.
Josh, thank you for taking time to post.
Rick, thank you for asking questions.
That is the entire point of these new forums :-)
us-east on Verizon FIOS issues
in Product Discussion
Posted
OK, for those on-lookers. I've just gone through about 15 of Tuly's accounts and now believe that the information he is posting here is not accurate. For the sake of avoiding any misleading assumptions by other customers, we CAN NOT produce any failing packet traces except from ONE of Tuly's locations thus far.
So, until I have something more conclusive that shows this is more widespread, please note that I do not think there is any issue on our equipment or with our network provider in EWR at this time.
Happy to investigate more reports, and waiting for Tuly to provide a more comprehensive list of where he's seeing failures, but at this point, I can't reproduce this, including to his own customers, so I want to prevent any FUD on this thread until I have more data.
I'll circle back when I've collected more data.