Rick Guyton

Hrm, I don't think it's router config. One of my clients is using a highly standardized router & firmware across all their locations. They have no issues at most locations. But, one does so regularly.

We seem to have never ending issues with BLF. I understand that some at 2600hz kind of write this off and think it's just for "old line key" users. And that is true to some extent. But, none the less it is vitally critical to the operation of some of our client's businesses. I've had two clients call me today to tell me that they are having more BLF issuses. So I believe there is a problem once again. But, the frustrating part to me is that I don't know how I'm supposed to even start diagnosing these issues. Can someone, anyone, please give me a concrete method to diagnose and resolve problems with BLF? I know that there's the presence tab under the debugging tool. But, I have know idea wat BLF states 1,2,3,4 or 5 mean or what PR stands for. Even if I did though, what about situations where some phones show different lights than others? Obviously, some phones will be in line with what the server's status is, while others won't. What can cause that? What can be done to prevent it?

What do you want is a DISA. It's available in advanced call flows. It asks for a pin code and then allows you to dial as if you were in the system. I never thought about using that to forward phones. Good idea!

Awesome, that'b be great!

@FASTDEVICE Yes, that's what we are needing too. Sure would be nice if it could be done without requiring a redundant license on the child account. But, heck I'd even pony up for that at this point...

Hi Josh, I've seen settings for this under Advanced callflows -> Devices -> (Pick a Device) -> Advanced -> Audio. And in the provisioner under the Lines section, in the advanced settings at the bottom. I have NOT tried this yet though! I had a client what as supper worried about it, then management changed and they didn't care anymore. So, I left it. But, when I was talking to 2600 I remember them telling me to go into these two areas and make sure I was using the zswitch.net domain and not a white labeled one. Maybe give that a try? Please post back and let us know how it goes! EDIT: I'm not sure how "supported" this is though... FYI

So..... about that redundancy issue with Peerless... Resolved???

Totally agree. Don't forget about call recordings! I kind of hate that call recordings is in the UI at all since it's almost completely non-functional for clients. Oh any analytics of any kind. :) But stability is king in our book and 2600 is kind of hard to beat on that front.

LOL, ok. Thanks for the clarification. I was raging for a minute there I'll admit. :)

I'm confused. Peerless is one of their providers... Why wouldn't they fully support them? Darren was talking about why peerless failed the way it did above and siad they were resolving it. I was just wanting a status update on that.

Hey Darren, can we please get an update on the redundancy issue with peerless? Has this been resolved?

So, I've been thinking about this a lot. Ya know, if there are conflicting extension numbers, there's a really easy work around for this. You could just add the star coded extension in the parent account. For example, If you have ext 100 in ClientAccount1, and another ext 100 in ClientAccount2 you could just add *60100 to the ext 100 callflow in ClientAccount1, then *61100 in ClientAccount2. If a user inside either account dialed 100, it'd goto THEIR ext 100. But, ClientAccount2 could dial *60100, it wouldn't be valid in their account, so it'd go searching in ClientAccount1, find it then route it. So, nevermind my last post, I think all you caveats would be fine. How do we get this ball rolling?

I tried to sign up for a whitepages.com account to change the caller ID and couldn't figure it out. Maybe I'm just not tech savvy enough. :) I also found an 800 number on T-Mobile's site and the option they say to press is no longer valid. If you drill down into their menus they pretty much redirect you to the site. My hate for the service is growing by the minute.

No that's what I thought at first too. But This is a staffing agency and Jennifer is a sales person. She calls local businesses and sells staffing services. But she she never actually talks with the actual staffers. But staffers were calling asking for her. We finally figured out that they were getting the name from caller id. Then figured out it was only on t mobile. So one of the staffing agency employees who has t mobile verified it came up as Jennifer on her phone. Then she called her husband from the office and it still came up as Jennifer. The husband doesn't even know Jennifer. So we had a few people submit that it was incorrect info on the caller id app. Hopefully that does it...

Sorry , should have been more clear. I'm having an issue with my clients coming up with the wrong name on t mobile cell phones. One of my clients has an employee named jennifer LASTNAME and when anyone from the company calls a T mobile customer the caller are shows Jennifer LASTNAME instead of the company name that's programmed in Caller ID.

Is anyone else having a sudden surge of issues with incorrect caller names coming up? Apparently Tmobile uses an app called  T-Mobile Name ID. I'm just finding out about this, but it seems like they use whitepages.com to supply names associated with phone numbers. This information has been wildly inaccurate for a few of my customers now. The only way to remove the info is to report it as incorrect from a t-mobile android phone. WOW... just wow... Anyone else seen this? Have better fixes?

Well, in a best case senario, it'd be nice to be able to have conflicting EXTs call eachother somehow. For example if ext 100 in accountA called 100@accountb.domain.com or *FETCODEFORACCOUNTB100. But, all the other "caveats" you've listed would actually be very beneficial to us. I mean it'd be nice if they could see BLF. But, I can code around that workign directly with the phones.

Yes, for us it's for extension to extension dialing between accounts. For us there's a two fold need. First, one of our clients keeps buying out other smaller businesses. If we could set them up on their own account we could retain their existing extension numbers, mailbox numbers, ect. All while allowing them to dial out to other accounts. This also prevents them from for example intercomming the CEO. (Yea, that happened) Second, it allows location managers to manage their own systems via SmartPBX without messing with other locations. This is a really big need for us.

:( Ok, need to find a way to transfer calls between accounts. I was hoping SIP URIs would do it. I know I can do it with DIDs. But that's going to chew up a heck of a lot of DIDs.

Ok, what about between accounts?

Ok, so to be clear, Kazoo can't receive SIP URI calls, only place SIP URI calls to outside systems?

Is there a way to connect from an external system using a SIP URI instead of a DID? For example if I have a device setup as user_2484 on a realm RingMe.mydomain.com, can I route calls to user_2484@RingMe.mydomain.com? Is there another way to do something similar? I know there's a SIP URI "device" but it seems silly to have to setup a whole new device for this.

Hey Darren, on the CNAM dip bit, I'm assuming you cache responses so that you don't have to dip every single time. Is that correct? If so, will the billing system be able to differentiate between cached dips and non-cached dips as to not charge for the former? Also, will a reseller be able to define the max life time of a cached CNAM on their respective systems so that we can balance responsiveness to changes VS cost?

I'm almost never accused of doing something the "new fangled" way. I need to take this in for a minute... .... ...... Wait For It .......... ............. Awww yea, that's nice. ;) Gun to my head, I'd use v1/accounts/{account_id}/webhooks. First, if you are relying upon webhooks for other parts of your app, you can double check it and make sure they are still there whit this data. So, at least it wouldn't be a totally wasteful request. Second, I don't think very many people even use this feature. So, most accounts will probably be empty. Those that do use the webhooks should only have a couple. So, in any scenario it should be a pretty small request. I'd still assume the token's good for some length of time. At least a minute or two. Can't imagine checking it before every single API call. The best docs I've found are here: https://github.com/2600hz/kazoo/tree/master/applications/crossbar/doc Maybe you can find something that works better for you. I don't see any functions that simply validate a token or return static data though.

Maybe do a GET on v1/accounts/{account_id}/webhooks if absolutely needed? If it returns anything, it should be pretty small.