Darren Schreiber

Hi Karl,      When you get your phones back online, let's run some tests, as what you're reporting doesn't make a ton of sense to me. It definitely should not be random. I'd want to see the phones in action, what packets we're sending to them, how they're responding, and how the callflows are setup exactly.      As for non-supported phones, it's up to the phone itself to respect the message we send. We send a message "Completed Elsewhere" per the RFCs that indicates NOT to show a missed call. It doesn't matter who ANSWERED the call, it matters that the phone which DID NOT answer the call can support the "Completed Elsewhere" message. I believe most phones do, I'm not sure on softphones though.

Now I'm even more confused. You had two phones, one had it enabled, one didn't? And then you're stating one of the phones did not show the missed calls? That would be the intended behavior, no? What kind of phones were they? The phone has to actually support this feature (Yealink, Polycom do, not sure on Grandstream or CIsco)

This is a configurable option in the GUI. Which phone is doing this? Can you screenshot what the configuration for this is in the GUI? If you provide the device name I can take a closer look. Would you allow us to place test calls to test this to that number (the support number) so we can observe this behavior?

We are actively discussing what it would take to build a module to let you just call between extensions between accounts. I think that would resolve this request.

There is actually a back-end module to do this but it's not in the GUI. I can see if we can document the APIs on it and how it works but it was community contributed and is largely untested so we could use some help testing it if you're interested.

Thanks for following up and telling us what you did.

I'm looking into this.

You also submitted a support ticket on this, but I'll answer here, too. The CDRs list the SDP that was offered but do not contain the ultimately selected codec. Feel free to file a feature request on this, it never occurred to me anyone would want that data :-)

This will be in the 4.0 release. I can see if we can get it sooner. The 4.0 release schedule will be announced shortly.

Could you be a bit more specific here? This comment contains no real content / factual data which would allow us to resolve the issue or explain how it works...

Glad you are coming !!! More to come.

This would frankly be expected I think. The literal way this feature works is that, while multiple phones are ringing, if someone grabs the call, the other phones get a hangup cause indicating the call was answered elsewhere (or depending on the setting they get nothing). However what you're stating seems to contradict what I'd expect. Would love some more data points if you're willing.

This is just a GUI issue to be clear, I know the function itself works. I suspect the issue is that initially the value is initialized to "blank" and then when you check, and uncheck, it becomes true/false. Perhaps the "blank" value is using the wrong default on the backend.

Karl,       When was the last time you tried this? Can you show us the configuration you attempted and explain what happened? What firmware were you on?

Tuly,     Can you screenshot the configuration you are attempting?

That sounds like a bug. Mind filing that on tickets.2600hz.com?

ThinQ was at KazooCon last year and presented. They're excellent in my opinion but you have to manage progress timeout issues periodically. I also know the founder from previous employment. Good people. We only use them for termination. For origination, we prefer a mix of Peerless, Windstream/Paetec, Verizon, bandwidth.com, O1, Onvoy and TNCI depending on LATA/Rate Center/pricing/usage/features.

Sorry,  secure-us-east.p.zswitch.net secure-us-west.p.zswitch.net

Yes, the initial failure issue should be resolved. HOWEVER, we're retooling our routing strategy with ALL our carriers and I was hoping to update this thread all at once with that info once it's finalized. So, stay tuned. More to come.

Hi there,      A few things on this. 1) Rick thanks for chiming in 2) Rick is right that the option must be set in the GUI. This causes the server to force SRTP when calling TO the phone 3) For calls FROM the phone, you must manually enable SRTP on the phone itself. I think it MAY be in the provisioner tool as well but remains untested to my knowledge. 4) Finally, for all this to work ,you must override the default proxy with: secure-us-east.p.zswitch.net secure-us-west.p.zswitch.net This is all in beta until 4.0 comes out because the SSL libraries in our current FreeSWITCH version are old and can't be upgraded without a massive overhaul (which is what 4.0 is) so this may or may not work well... Hence why it remains unsupported, but available. It honestly should be OK but your mileage may vary. ALSO, because it's encrypted, WE CAN NOT debug audio issues if you turn this on if they're between your customer and our server.

Interesting features. We can file these as requests but these are not on the roadmap for anytime soon. Thank you for the ideas, though. I think we've heard the missed call one before, though that sounds insanely annoying to me but I guess if this now keeps getting requested, people must like it...

@Rick thanks for the comments on stability. Re: call recording, yeah, working on that now actually. Stay tuned.

See below... 1) there should be an option to have settings changed for all future accounts that we open (so we should not have to change 30 settings on each account that we open) > We are debating a way to copy an existing account (so you can make a template account) to a new account. This should solve this. No ETA on this, won't be until at least Q1 or Q2 next year because we are working on other things like call queues ATM. 2) record a call with a DTMF > This is pending, stay tuned. 3) we should be able to "find me fallow me" to another extension > Don't get this one at all. What value is this? This is a bizarre case I've never heard of. 4) schedule's should have a End date and time (the same way it has a start time) > No idea what this is referring to. 5) there should be a way to set provisioning setting across ALL accounts (line BLF and park,  are the same on ALL phones) > We probably won't do this. We've made it pretty quick and painless in SmartPBX to set the BLF lights. It really doesn't take that long and we discourage people from creating key-system like setups anyway, this would just promote more people doing that and it's a nasty, nasty thing to have hundreds of unneeded useless SUBSCRIBE/NOTIFY packets flying all over the place. Also it's really hard to get all the buttons to map the same across multiple models of phones. So, the work required here is likely way too high. 6) there should be an "easy" way to set a forwarding or any other setting on the fly.. (a client calls in "our internet just want down, transfer our number right away to my cell phone till 4PM" > Login to the user portal, there's a call forwarding setting? How can this be any easier? It's pretty easy already? 7) missed call notifications are still missing.... > No idea what you mean here. 8) the user page looks very very outdated and missing many many features,, > Yup, agreed and this is on the roadmap for Q4 or Q1 at the latest. 9) provisioning should have a text box, where we can add our settings across all accounts, > We debated this but then we'd charge customers if they broke their own configs, because we don't want to be the provisioning "janitorial" service for people who break stuff because they're playing with it. Then customers complain they shouldn't have to pay for just using a feature or adding their own stuff because feature X doesn't exist. Soooo not sure how to mitigate cost here. We're moving all customers to hour limits/blocks so once that's complete I'd be more open to this one.

I've added it to the feature request list. Right now it's behind a number of other items so we'll have to finish those first. You'll actually see those getting announced shortly.

This is an app T-Mobile started pre-installing on phones from what I understand. It's powered by whitepages.com . There is a button on the phone to report incorrect Caller ID Name from what I've read as well. But it is not based on the standard CNAM database. It is whitepages.com's own database. They have a blog article about how to update the Caller ID Name if it's wrong: http://blog.whitepages.com/take-control-update-your-caller-id-whitepages/ You have to sign up for an account on their system, verify your phone number, then you can update the Caller ID Name and add a picture. To be clear, this isn't really the US Caller ID Name service you're used to. It's an imposter T-Mobile is shipping.