New Porting App Feedback

[Rick Guyton]

So, I've been submitting my ports via the porting app. And I'm not loving that the numbers aren't available for assignment until after the port completes. Optimally, I'd like for the numbers to be available as soon as I request the port. Or, at the very least once we have a scheduled date for the port. This way, I can very efficiently setup a client in one shot. As it stands right now, the numbers only become available once the port completes. Maybe I'm missing something, but doing it this way forces the client to have a full system outage... Yikes...

[Darren Schreiber]

Yup, this is agreed. It was actually an internal miscommunication (see Karl's comments about it previously) where that is how it was SUPPOSED to work, but apparently it's not actually doing that. We're working on that (and retooling more bugs in the port tool).

Net - net, we need people to start using that tool. Why? It allows us to integrate into automated ports so there are less delays in processing ports and you're in direct communication with the provider when there are issues. It takes us out of the loop (saves time/money) and speeds up your port submissions (yaaay) and also avoids errors (our guys can't "typo" things) and fixes billing.

So the advantages are high, but yes, the experience needs to be more functional, so, working on that. One step at a time.

[Logicwrath]

Rick,
At least for now, after you submit the port you can request that they manually make the numbers available for configuration.  This is usually good enough to get things configured.

My biggest complaint is that there seems to be 2 ways to make the number available.  One way makes it "local" and when it is local you can't configure E911.

The other way, they complete the port makes it more official and all configuration options are available.  I would very much prefer to be able to configure E911 on local numbers or just get rid of the "local" status all together and stick them in like normal numbers.

In any case I want to be able to configure E911 right away without having to configure a temp number and then later configure the actual number. 

[Darren Schreiber]

"In any case I want to be able to configure E911 right away without having to configure a temp number and then later configure the actual number."

This is actually not going to be allowed much longer. Basically we can't guarantee the E911 update works properly if another company has the number still with the upstream provider, but the upstream provider is the same despite it "porting". This is an edge case we've run into and is a big problem and has nothing to do with us frankly. The upstream provider clears the E911 after the port and then we have to have a way to re-apply it without knowing they did that.

[Rick Guyton]

Yea, I've done that, but it's just more and more steps to keep track of. With the old ticket based system, I'd just send me client a form and when they went it back to me, it was ready to send to 2600, old bill and all right there in the zip file. Now I've got to transcribe all that info into the app and upload the PDFs separately. (more steps) and I have to make a separate request after the port starts to get the numbers available. This is on top of keeping track of the temporary number and setting up the 911 after poring completes.

I was just really hoping that as a trade off for having to transcribe the info all myself, I'd at least get instant access to the numbers for config... Oh well.

[Darren Schreiber]

Hi Rick,
     The goal is to have instant access to config EXCEPT E911 until the day the number ports for E911. Then it will be just as fast (or faster) than sending it in as a ticket.

[Rick Guyton]

So, a thought... What if you extended the porting app to become aware of a temporary number. So, for instance when I put a port in for 480-123-4567 and 480-234-5678, the porting app offered me a temporary number of say 480-345-6789 or whatever was available from a 2600hz carrier and asked me to configure 911. Prior to port completion, you know to re-route 911 calls from 480-123-4567 or 480-234-5678 to the 480-345-6789 number. After port completion, you can copy 911 settings from 480-345-6789 to 480-123-4567 and 480-234-5678. Then, remove the number. Sweet huh? :)

I could almost do this myself. But, that 911 redirection thing would have to be internal...

[Darren Schreiber]

Honestly messing with the E911 logic is about as attractive as getting a root canal. If we break any of it, we get blamed, so while it may be more convenient for you, it really is less risky to just ask resellers to, on the day of the port (When you're confirming the port was successful anyway) re-check 911. You should be dialing 933 anyway as soon as the port completes to verify that the 911 address took to start with. This is the best procedure out there to be sure things are really correct.

I'd rather save you time/energy through automation via the porting process itself, which is what we're currently focused on.

While your idea is sweet, the implementation is a nightmare and the risks are very high if anything goes wrong (And all of the risks land squarely on our shoulders i.e. labor costs).

[Logicwrath]

Wow, 933.  Learn something new every day.  Is that documented somewhere?

[Karl Stallknecht]

Ditto - I always worried and wondered if there was a way to test e911 without actually calling 911. Now I know! Thanks!

[Darren Schreiber]

I am working on a guide to "how 2600Hz recommends setting up, and testing, new clients" and also some recommended firewalls. They are old asks that I think we are comfortable answering with more confidence at this point regardless of the installation type.

This will be part of that.

[Karl Stallknecht]

Hmm okay so maybe my logic has been off....I always assumed that if we setup a new client (prior to the port) that if we set the e911 caller ID to their existing number (the one that hadn't yet ported) it would be fine because the 911 info would be coming from their current carrier, not us, if they called 911. Is this incorrect?

[Darren Schreiber]

It's frankly even worse than that actually.

The reality is E911 doesn't come from the upstream carrier at all. It is overlayed by a third-party carrier (bandwidth happens to have purchased Dash but it's still run as a separate service).

Imagine 911 being a completely different company. (In fact, if you wanted to, you could simply buy 911 and never buy minutes at all!). It has nothing to do with the phone number you bought OR the service you have OR where the service currently lives.

Instead, when you dial 911, we send the call to a special company that is NOT the normal carrier. (This is what everyone does in VoIP). THAT company then ships the call to a PSAP (Public Safety Access Point) in the area where the Caller ID is set.

So when you are setting E911, it has absolutely nothing to do with the port or the number. Heck I can set E911 on the whitehouse's main number right now if I wanted to.

And that's exactly the problem :-) We have no ownership of the number, and someone ELSE might ALSO be setting E911 during that time period/window while the number is being transferred. This can cause various issues. Thus, we really should not be allowing E911 to be set until we are sure we actually own the number.

[Karl Stallknecht]

Right, that was how I understood it...so using that logic, I always thought that if we set the company/device's e911 number to their existing number (which hasn't ported) then it will continue to use whatever was set by the company before us, so it will be fine assuming what was set by the company prior to us is correct.

[Darren Schreiber]

That was our assumption, too. For a long time. And it generally works. Except when it doesn't. :-) Which is the problem.

The issue is, if the OLD carrier happens to ALSO use the same 911 provider as we do, and the OLD carrier complains about the data being wrong or requests the data be removed when the number ports out, the carriers sometimes screw up and erase our settings (or their system can't handle the difference between the accounts and erases our settings). Thus, we lose the E911 provisioning.

But we think it's still provisioned, so we continue to show it as such in the portal.

Of course you only find this out once the customer goes to actually dial 911. EEK. Nasty. Which is why we're putting an end to this.


Soooo with all that in mind, I'm all down to optimize the crap out of the port process and automate almost ALL of it EXCEPT the part for setting E911. Which I really think, for sanity, we should ONLY do when the number is owned by us and the port completes.

[Karl Stallknecht]

Sorry, I think we're still on different pages...

What I am referring to is ONLY while we wait for the number to port. We do not set an address on the DID during this period. All we do is set the customer's main phone number as the 911 outbound caller ID number at the account level (or device level).

Once the number ports, we usually wait 2-3 hours and then go set the e911 address on the DID.

[Darren Schreiber]

OH! Yes I think that's a good idea, except don't forget they may have already hooked up their phones to our system if you're giving them new phones, so if they dial 911 the right Caller ID transmit but there will not yet be an address assigned to it.

[Karl Stallknecht]

Right, but the caller ID for 911 will be set to their existing number which should already have an address configured with it from the existing provider. So it doesn't matter, correct?

[Darren Schreiber]

If the existing provider does not use our same service provider, than no, that is not correct.

[Karl Stallknecht]

But I thought it wouldn't have anything to do with you? The call gets routed to the PSAP and they see the existing number, which already has an address configured from another provider...

[Darren Schreiber]

That's not how it works.

The PSAP does get the call, yes, but they get the address information about the caller from whoever sent them the call (the company we contract with). They are paired together.

Example:

You port a number to us from RingCentral. But RingCentral is really using bandwidth.com and Dash E911. We are also using bandwidth.com and Dash E911 for this port. RingCentral has configured the number with an address. You go into the portal and configure a different (or the same) address on the number but we don't own it yet. It's POSSIBLE that when RingCentral releases the port, they contact Dash and tell them to remove the E911 mapping. Dash is SUPPOSED to be smart enough to NOT delete what we put in and only delete RingCentral's data. But, sometimes they screw up, and they delete the data from both. Meanwhile, we think E911 is actually set, so we show you the setting on the screen showing it's set. But it's not. Fail. When 911 is dialed, Dash transmits the info to the PSAP with number + address, except there is no longer an address.

Another example:

You port a number to us from Verizon. Verizon has their own interconnects with PSAPs via alternate parties. We use Intrado for our 911 on this particular number. Verizon sets an address on their equipment. You do not set 911 address on our portal (so it's not set on Intrado). The customer then dials 911 from their new VoIP phone. Well, we route that to Intrado, who locates the PSAP and sends them the Caller ID + Address. Except there is no address. So, no E911. Even though Verizon still has the address paired with the number, that's via THEIR provider on THEIR system, not Intrado.

[Karl Stallknecht]

The first example I understood, which is why we always wait to set e911 addresses until after the port completes.

The second example I didn't realize was the case. I assumed that the PSAP would get the caller ID number from you, and then run a search to see which address was associated with that and then the address info from Verizon would pop up.

[Darren Schreiber]

No, there's no central database (unlike Caller ID Name).

You are correct, however, that Caller ID NAME lookup works that way - it looks at whoever set it last globally - regardless of the carrier. But not E911.

With E911 the address info is transmitted by whomever processed the call to the PSAP, which in our case is generally either Intrado, Level3 or Dash, and it's up to them to get it right. And sometimes during the port process they seem to screw it up (like only 1% of the time). But it's not worth the risk.

So, that's why, again, if we're going to save people time and effort while improving the process, I'd rather:
* Automate generation of LOA and RespOrg forms that you give to the client and apply your white-labeling automatically
* Automate validation that the area you're wanting to port TO is serviced by us
* Automate submission of those forms once you send them back, all the way to the upstream carrier (saves possibly 12-24 hours of processing)
* Automate responses from the carriers direct back to you
* Intervene on our side only when you actually need our help and we add value (saves you time and us time & money)
* Eventually get E-sign enabled with the above so we can avoid needing physically signed documents

The above should save lots of headaches. To the point where the only step post-port will hopefully be E911.

[Rick Guyton]

Ok, I'll ask the stupid question I guess. Why not allow us to provision e911 on (in dash). Then just resend the 911 provisioning API call to dash again upon port completion?

[Darren Schreiber]

I guess we could do that, but there's no automated background script to do it. So you would want us to allow E911 provisioning, and then you'd come in again and save it again post port-in to re-send it to the upstream provider upon port completion?