Darren Schreiber

I'm sorry you feel this is no longer simple. I think it's really the same as before, though? Just use the Advanced Callflow editor for this. This is not a standard PBX extension if you're having it ring through multiple people. Hence the purpose of the advanced callflow editor.

I'm going to selfishly bump this :-) Even though I usually forbid bumping a post. You all said you wanted call center! This is the foundation for it :-) w00t w00t

Hi Logicwrath,      I finally got some time today to try to get my test TDM line up. I just wanted you to know that this is progressing, albeit slowly.

Hi folks,      Wanted to make sure everyone saw this. Hope some of you will join us! Would people also be interested in a "partner" strategy session? One where we cover secrets, tips and tricks + training on new features in the GUI? Would you be able to do this in person? If so, where?

You're trying to mimic a key system and do shared line appearance. I suggest telling the client this system doesn't work that way. Teach them instead how to use BLF + Parking as Karl had described. They resist at first but usually fits the same office "workflow" so is not a huge deal.

Yes, it is a mess. I know BLF seems like "just a light" and that is why everyone gets so mad at when it doesn't work, but yeah, what you're looking at is literally why it is such a mess. :-/   I'm sure it seemed like a good idea at the time when those people implemented it.

This line of questioning is a bit suspect. Are you asking for a definitive way the packets work? The problem here is in RFCs in general, specifically because of RFC 2119: The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5]. The word "MAY" is the root of all evil. In fact, the FreeSWITCH team has a running joke about it when advertising their conference, ClueCon - you SHOULD attend, you MAY learn something. ;-) Or something like that. Anyway the joke is pretty simple. Because the word MAY is used in the RFC in various spots that are really ambiguous, different vendors end up implementing whatever they interpret that word to mean. Thus, you end up with different implementations. The word MAY exists in the RFC for the goal of ensuring people can use the specification in differing ways, but it ends up serving as something that creates issue when two people trying to implement the same functionality do it in different ways. Thus, a mess. Thus SIP :-) So, if you're asking "what packets exactly can be transmitted", the answer is read Luis's specified RFCs . EVERYONE - including Broadsoft and Asterisk - MUST be following them. But not everyone MAY agree on exactly how the RFC reads, thus, the implementations can take a while to get right on each platform. Trial & error FTW

Hmmmm  you seem heavily dependent on faxes in general, what is your use case in general here? Are these insurance companies or something? Doctors offices? Who is doing all this faxing? I ask because I wonder if you want to actually just test a TDM test install I have. I don't know what threshold of pain your client is willing to put up with but when you say things like "they fax this number daily" I worry that the issue will recur and they'll have a bad experience. There is another post on here about fax ATA devices, perhaps that is a better route for this particular client?

You can't compare our service to eFax. eFax is a TDM-based service, and ours is a VoIP based service. We can't guarantee 100% completion because we use VoIP carriers (which keeps the costs low and avoids patent issues) but the downside is that there can be completion issues, sometimes chronic. The way we usually deal with these is, as we receive reports, we check the Caller ID and the dialed number and identify which carrier is being utilized. We then switch to an alternate carrier for that route. But you should expect to get reports like this over time until the common areas a particular client is faxing are "tuned". Unfortunately we haven't found a better way to do this other than investing in our own TDM bank, which we wanted to do last year but we ran out of room in our datacenter. Luckily (see other post I made) we are moving to new datacenters next month, so hopefully we can revisit this issue. What was the area code and prefix of the Caller ID on the FROM number, and the same for the DIALED/TO number? I can see if we can try taking whomever the call completed on out of rotation and see if that improves reliability.

Hi everyone!       We've heard from a lot of you that you are looking for more transparency and information about what we are doing here at 2600Hz to enhance your experience, your software and your ability to generate revenue. I wanted to let you know that we've been heads down on making that happen for quite a while now. We're now at a point where we have some new stuff rolling off the "assembly line" that we want to tell you about.       We'll be sending out a more formal notification about maintenance and upgrades to everyone (via email and the announcements page here) shortly, but in the meantime, the first thing I wanted to give you a heads up on is our datacenter upgrade project.        For those of you hosted in our datacenters, we're excited to tell you that we're upgrading to new hardware, new racks and faster internet peering connectivity with our upstream providers. All of this is supposed to be transparent to you, but will pave the way for us to start rolling out more software and hardware based features, while also speeding up our systems. There are two products in particular that these upgrades will allow us to rollout, and I think you will like those features a lot... but we need the space to get them done. Once we're upgraded, we'll announce the new features.      We will also be opening a new facility in Chicago and moving out of our old Rackspace facility. This will result in some new IP addresses for where we send audio from (the SIP signaling addresses won't change). So we're giving you as much notice about this as possible for any of you who have clients that maintain firewalls and strict security access rules. I'll be publishing the new IP ranges shortly.     You don't need to do anything to prepare for this upgrade (unless your clients have super strict firewall security and demand knowing every IP you use). The changes should just happen. There will be a brief maintenance period where we will need to take our load balancers offline (one datacenter at a time/weekend), but if you've programmed your phones with a failover load balancer then your customers won't notice a thing. If you haven't, they'll have a tiny bit of downtime but it will be after standard business hours and you can notify them in advance of the work. We can also help you re-provision phones to an alternate datacenter in advance, as needed.       We're targeting the first move for our New York datacenter on Friday, 5/6 in the evening. We're hoping to move our Silicon Valley datacenter on Friday, 5/31 in the evening as well. We'll be turning up our Chicago datacenter sometime in May as well but that one won't impact anyone or have any downtime, just new IPs that we'll start sending traffic from. And again, we'll publish a full list of our new IPs so everyone has them.        You shouldn't need to change any DNS entries, branding, portals, etc. and there will not be a software upgrade during this period - just the same software (for now) on new hardware and in new racks at our datacenters.         I wanted to post this here in case folks had questions and also to give you all "first dibs" notice at what's happening. This work has been in planning and negotiation stages since January and our team has a solid plan for making this all happen fairly transparently, but we're always happy to hear about ideas and concerns, so let me know!         This is a big project coming to completion, and it will allow us to finally start rolling out features that some of you have been waiting for (for many months in some cases), so I'm excited for the next few months. Going to get very busy around here, so stay tuned!         Thank you all for your continued support of our platform, our products and our services. Without you, none of this would be possible!

OK, interesting. So what I will do is I will ask the UI team to add this to the advanced callflow tool. Thanks for your feedback.

Yes, because a user is a person! That's the idea anyway. Any most people have email addresses. I am surprised to hear this is such a problem so we need more data to understand why. Then we'll figure out a fix.

OK, thanks, notified the UI team about this, too

Yuck, adding bogus addresses is nasty. It generates a bunch of bounce backs on our side and makes it hard to keep deliverability status high if people mark it as spam from a random domain. Please don't do that. Please file a feature request detailing what you're trying to do. Is it really that there's no email associated, or is it that you wish to prevent login to the user and/or voicemail to email notices? Please be specific and we'll find a way to solve it.

We're currently playing with ideas of a media, voicemail and/or fax management portal based on the energy on this and the fax thread, FYI.

I like this idea a lot. Can you post this as a feature request in JIRA? tickets.2600hz.com

You can not do all those things, just the basics listed. You can file a feature request for this, though on JIRA. tickets.2600hz.com 

FYI, we're continuing to work on this. Luis may come on here and ask some clarification questions.

On the hosted shared platform you can use the Reseller Reporting tool to download your CDRs and your costs, per month, per-account. They are broken into individual CSV files for you. We are working on expanding this further. One other thing we're doing relates to a new offering we'll be announcing quite shortly :-) Should help with this.

The original post (at the top) specifies resolution. "fax_info.fax_result_text: Far end cannot receive at the resolution of the image" You stated "a customer of ours received this same error" so I'm assuming you're referring to the same thing.

It can be page size OR resolution that it doesn't like.

OK, so then perhaps we just need an account-wide mailbox manager?

But this problem doesn't seem chronic? We've probably had 3 or 4 voicemail to email delivery issues in the past 6 months, which lasted several hours. Your client received 200 messages in just a few hours?

That is true, but this post makes it sound like you are having to delete hundreds of voicemail messages?

You can login as the user and then use the user portal to mass delete. But why not just check the box to delete the voicemail after sending an email?