Darren Schreiber

This is in the works. No ETA quite yet but we're getting there.

Drop me a note at darren@2600hz.com with the attachments. I'll give them a try and see if we can tweak the converter we use that might be reducing the resolution.

We can offer phone numbers in other countries, but the traffic always routes back to the U.S. (for now). If that's what you want, then you should write into support and they will help you.

Would you mind reporting back your experience with this new feature?

"Far end cannot receive at the resolution of the image" is your clue. It's actually probably correct and not a Kazoo bug. Each page has a resolution and a size (which I don't believe we set, it's in your original file). Sometimes, for example, you might have a piece of paper that the original fax machine or scanner treated as a legal page size instead of letter. On each page transmission we tell the remote end what size page to receive (standard fax stuff). Some fax machines are literal - if you tell them it is legal size they'll go look in their trays for legal paper. If they don't have it, they'll reject. Other machines it's simply about the quality of the resolution you're sending - it might simply be too high for the remote end so it rejects it. Try resampling your image to a lower resolution and size and re-send. See if that works. This might be a neat idea for a feature request. We could study more generally accepted sizes and see if we can auto resize before sending. Of course, the receiving end then might complain that everything came out looking tiny...

So actually when you select Soft Phone we inherently know that the phone is probably going to roam. So we are supposed to disable, by default, and without option, the notify on de-register. So it sounds like maybe there is a bug or the GUI team did not understand this when it was coded up. It may have been missing from the spec or engineering design discussions. I will talk to Aaron and see if we can get that resolved.

@FASTDEVICE I agree. That said, this feature has a significant impact on call processing (tone detection is expensive). I'd like to see a small number of people try it first before we commit to formally rolling it out to all via an easy-to-use GUI. We can take the feedback from those that tinker with it and make sure it works / is better before rolling it to the masses. So let's consider this a beta test at this point. In the meantime, I'll meet internally with folks to figure out how to add it to the callflow editor. There are enough people who know JSON and can use Curl that perhaps we just start there (I think you're one of them?) In parallel, we can work on making it available via the callflow editor via the design team.

So based on the interest in this question I asked our team to dig into this. It turns out there is infact call detection already built in, I just didn't know about it ;-) Luis has documented it. I don't think a single person has tested this so please try it out and feel free to report back your results. https://github.com/2600hz/kazoo/blob/master/applications/callflow/doc/fax_detect.md Please note, I think 3 second default is too short. I've put in a ticket to make it 4 or 5. But it should really just work.

Yes but you need to negotiate them with a sales rep. Note that call center is a risky business. If they're inbound it's not as bad, but for outbound, a lot of times they are calling to high-rate areas. Despite us offering YOU a flat-rate per-minute, the reality is we pay a varied rate on each destination you call. Normal office PBX usage usually means your calls are in the local area, or they are to random areas and so the numbers average out. We take on the risk in case we're wrong. But a call center often tends to hammer away at high-rate areas. So if they call Oklahoma all day long at $0.15/minute, we go bankrupt :-) Soooo we scrutinize these deals pretty heavily before we give the OK.

I believe Ops has acquired the new cert but has yet to install it. So, yes, try http:// for now. It should work.

re: discovery, that's one of the initial problem areas. You're going to have to combine an initial API call w/ WebSockets updates basically.

Ironically, the code WAS released last year basically (about 9 months ago). We've only turned it on for some beta customers and some dedicated customers. And we've learned about a whole bunch of problems with it, ranging from there not being enough events implemented for it to be useful to it being unstable. We're actually pretty sure we've addressed most of those items and I'm hoping to take another crack at turning it on for the masses this week. Thanks for your continued patience as we work to roll out this fairly challenging feature.

NP

Yup. Which means the same firmware "series" has different DNS features depending on the model. Which is why it's irritating. I'll ask Peter on Monday to look at these again and make sure that we're defaulting to 0 for phones with DNS-NAPTR.

Alright, I'll check in with Peter Lau on this. Grrrr Yealink inconsistencies. 

Perfect. So are we populating the 0 or did you enter that?

Mar 19 05:12:26 SIP [530]: SUA <5+notice> [000] host=us-central.p.zswitch.net, transport=3, port=7000, family=2 Mar 19 05:12:26 SIP [530]: DNS <5+notice> [DNS] us-central.p.zswitch.net is not found in dns cache Mar 19 05:12:26 SIP [530]: DNS <5+notice> [DNS] set DNS timeout=3000, tries=2 Mar 19 05:12:26 SIP [530]: DNS <5+notice> [DNS] About to query 'us-central.p.zswitch.net' IN A/AAAA Mar 19 05:12:26 SIP [530]: DNS <5+notice> [DNS] dnsutils_dns_query succ ! Mar 19 05:12:26 SIP [530]: SUA <5+notice> [000] DNS query:Successful completion It's not even trying DNS-SRV. transport=3 hmmmm.... Can you try changing the port number to 0?

You ran a PCAP. That's not what I'm looking for. There's a place to hit EXPORT to export the syslog.

How about this. If you send in your IP address (in a support ticket) I will go ahead and block it so you can re-test.

Also, if you're on the same firmware as me, you should see DNS-SRV not DNS-NAPTR. I don't think your firmware changed. Please re-post your configuration on the firmware mentioned above and also screenshot the firmware & hardware ID so I can see those.

I just tested this again. It works properly with the setup I screenshotted. To test: 1. I setup the phone with only a single proxy 2. I placed a call, watched it go via us-central 3. I went onto our us-central server and blocked the IP/port 4. I placed another call. Watched it go to us-east, as it should have. The behavior is correct and working. The firmware I'm on is the same as you.

Go into Phone / Configuration. Turn the loglevel to 6 or whatever is highest. Confirm it. Then reboot the phone. On boot, go back to that same tab and Export the log and post it here.

We do push the firmware. However, it's not been working we discovered since we moved to HTTPS. The phone is refusing to download it. Apparently it doesn't like certs from GoDaddy. Next week we'll change the cert to VeriSign. Then the firmware will be offered, and consistent.

Can you try 28.72.0.45 ? http://support.yealink.com/attachmentDownload/download?path=upload%2Fattachment%2F2015-3-10%2F6%2Fb6... That's what we tested with.

My best guess at this point is that these are all due to discrepancies in the firmware versions. Why don't we pick this up once I get the firmware version list from Peter and we can try to at least match that.