DID Forwarding?

[SUSD]

3300 MXe - 2 clustered  4.2 / 10.2

Working with DIDs is something new for me since just starting with this hospital.
Telco provides us 3 dry pairs to one of our local Dr's Offices. We provide them 3 DIDs to a key system.
The office is expanding and Telco cannot provide any more pairs. So as usual with our more distant offices, Telco will have to provide them new local CO lines on their key system.

My questions,
1. How are we sending the current DIDs to them ?  I have to find the dry pairs we are using, but, programming wise, how is it happening ?

2. Future forwarding options ?  To provide transition time until the new number is established, maybe 1 year.
A. Can I forward the current primary DID to the new CO line they will get with the 3300 ? OR
B. If I can't do it in the system, then Telco should be able to forward it, but it may cost me ?

Appreciate the help.

[acejavelin]

The most likely issue here is the "DID"s you are providing them are nothing more than analog extensions off of the Mitel, and they are connected to the key system as standard copper "trunks" except you are acting as the CO essentially.

1. Programming wise, lets say the DID number is 751-5500, then their is probably an extension 5500 or a system speed call pointing 5500 to something. The most likely case here is there is a hunt group with a pilot number of 5500 and three extensions that could be anything. Like anything else if you don't know where something is, start with something you know (the DID number) and trace it through the system, you will likely find it points to a hunt group with three analog extensions and those are tied to your leased pairs.

2. Forwarding options are easy, point the DID to the new external number via a system speed dial entry (5500->9-222-2222)

Not sure I understand the rest of your question.

[Mattmayn]

Another thing to consider trying is adding the new numbers to your current hunt group as speed calls that way there is only one pilot number for the calls going to the remote office. You could enter the individual numbers or if they are in a hunt group from the tel co you could just point to the pilot.

If you have the CO forward them you would most likely defeat the purpose of what ever you are trying to do since you would lose the 3 trunks on the dry pairs at that point (for inbound at least).

Have you considered a decent data link and IP phones? I assume the remote office is owned by the hospital, that seems to be the trend around here anyway.

[SUSD]

Mattmayn,

Since I'm limited to 3 pairs to the remote office and they want 6 lines now, they would get blocked after 3 of the lines are in use ?

If Telco provides them the 6 CO lines direct, they wouldn't have that issue.

I have to investigate the option of giving them IP phones (licenses, buying the phones, our bandwidth to them)
I like this option you suggested. I'm not sure how it will be received by admin.

[acejavelin]

Remote IP phones are clearly the way to go, although they do require a little more work, at least initially... And  would depend on if there is a VPN in place or not... If there is, assuming sufficient bandwidth and network performance, you can add a route from their subnet to the voice VLAN and just put the phones in Teleworker mode and punch in the IP address of the 3300.

If there is not, then a Mitel Border Gateway is the way to go. The upfront cost is higher, a server, licensing, static public IP address, but in the end this is a very efficient, secure, and powerful way to manage remote phones anywhere in the world. Honestly, copper/analog leased service is a dying thing, where I am it is difficult to get in many places since fiber to the home is so predominant and IP connections are so cheap (like 200M down/30M up and 250 channels of HD TV for $65/month in the rural areas around town).  MBG also has some neat features like acting as a SIP Border Gateway, opening up possibilities of SIP trunking and SIP endpoints off the Mitel as well, which can significantly lower operating costs.

Now is a good time to plan this out and start implementing, since in the future this type of service will become a thing of the past.

We have large "campus" type environments, with multiple offices across the city, around 1000 phones scattered in 20+ locations with 10 controllers in a cluster and about 100 remote phones, it works exceptionally well. Mitel clearly has this technology down, I would suggest a meeting with a competent Mitel vendor to discuss options about migrating away from this type of analog service and moving to IP, if not for just this situation but to future proof your telecommunications infrastructure... and leased lines are not cheap (at least not around here).

[johnp]

I would assume the co is supplying opx circuits, unless the distance is short. Since you say the far end is a key system, you would need to be concerned with it's co capacity. I would assume the DID's are analog extensions hosted locally and appearing as a co on the key system. I also agree an IP solution would be best. I suppose more info would help.

[SUSD]

First,  Thank you all, as you have helped me to understand what was done here previously.

I am going to push the concept of going all IP, but I do need to research the Teleworker info so I an understand it.

Back to my DID issue. First, I looked around, in the system and other posts. But I cannot find the 400 DIDs in the system.

So to say "Call forward a DID to a Speed dial" or point a DID to an OPX, I can't find the starting point for that?
This is my main concern at the moment.


Someone suggested the following to show all the DIDs: 
Trunks/ Digital/ISDN/Outgoing call Chars/DID ranges for CPN, Then look CPN Substitution

However, that only showed one DID Substitution.

Thanks very much.

[619Tech]

The DID digits being received from the carrier may match your extension numbers (DN). Check your analog stations and see what the DN's are. If they match the DID DNIS being received by the carrier, the routing happens automatically. The CPN substitution is not required, so there may not be entries for the numbers you are trying to locate.

[acejavelin]

DID's can be handled in multiple ways... say the number is 201-222-1234, you may receive any number of DNIS digits from the telco (34, 234, 1234, 21234, 2221234, 7012221234), so depending on your extension length and configuration how these are routed can vary a lot... if the DNIS digits match the extension number length, just do a LOC NUM xxx in maintenance to find what it is (extension, hunt group, ring group, etc), if they are different, this is usually handled in System Speed Call (2221234 is speed called to 300 for example). Some browsing around and playing with the LOCATE command in maintenance will probably yield the answer.

In the configuration you mentioned earlier, the most likely scenario is the DID is pointing to a Hunt Group, either directly or via a system speed call entry, and the analog extensions are members of that hunt group, allowing calls to roll over to "line 2" or "line 3".
Another useful way to do this is have them pickup each line and dial "0" (or a another internal extension with a display) and have the operator look at the display when they answer it to see what extensions these are.

[johnkeri]

Tracing calls on digital links the easy way is in maintenance.
EDT TRACE VDSU NAMNUM (PLID)
This will show a simple flow of calls on the digital link you want. Don't forget to turn it off by issuing the same command again!
Now dial the DID number and see what else pops up.
The number of digits you are routing is obvious right away. If the call is translated and rerouted out, you will see the that call too.
Once you have the incoming DID digits (3, 4 whatever) use Locate number to find out what that number is.
Then just follow the yellow brick road.