Non-Existent DNs - Play Message?

[bioreit]

Hi,

We have a Mitel cluster comprising of:

MiVoice Business 8.0 SP1
MiCollab 8.0.0.40
Mitel Border Gateways 10.0.0.116 running MSL 10.5.19.0, plus loads of other servers (if needed for assistance let me know and I'll edit this)
Connected via SIP trunks to our provider

We were wondering if it was possible to set the system up so that when an inbound call to a DID from our SIP provider is presented to the Mitel, and the corresponding DN doesn't actually exist, that a recorded message could be played (we'd record and upload something along the lines of "Sorry, that number is not in use").

At the moment, Mitel sends back a 404 error (great, normal, expected) but our SIP provider treats that as a possible error with that specific SIP server of theirs, so works its way through all its SIP servers in turn. Once it's had a 404 error on all servers it kills the call attempt, but the issue is that this is sufficient for our firewalls to treat this as an incoming brute force attack and block *all* inbound sip traffic (not great...)

We're in talks with our SIP provider, Mitel support partner and also our firewall guys to see if there's any solution we can do, but experience tells me it will be several weeks at the very least before we get any movement. So i thought I would ask here in case someone knows a way of doing this?

Should also add that we use flow-through provisioning via MiCollab and our Active Directory, so that when someone leaves their extension is automatically deleted, so this would need to be some kind of global catch-all setup and not a manual one, as we have several thousand extensions in use and missing just one newly non-existent DN for a few hours is potentially enough to cause this issue.

Literally no idea if this is possible - if it isn't, it isn't and that's ok -just thought I would ask those with tonnes more knowledge and experience than I have!

Thanks,

Bioreit.

[sunspark]

I've never seen a problem like this, but what you can do in the meantime is create a phantom extension and redirect all did number that are not used to this extension

[sarond]

I would investigate "Intercept Handling"

You could create a RAD Greeting that play the message "The number you called is not in use, please check the number and try again"

In the Intercept Handling for unassigned DN you send it to the RAD.

[bioreit]

Thanks @sunspark and @sarond for the quick replies!

I'll look into Intercept Handling and see if that can do what we need. I'll reserve the forwarding option as a backup - I'd prefer not to go down that route as it will mean an awful lot of overhead to maintain, as extensions are automatically deleted when the corresponding user's AD account is deleted when they leave, and with several thousand active users (and an even bigger pool of currently unassigned extensions) that will be one heck of a lot of work!


But really, thanks again both, much appreciated!

[lundah]

Yep, Intercept handling is how to do this. In Intercept #1, set "Unassigned directory number - Directory Number" to the DN of the message you want to play or number you want to direct those calls to. So you can send those calls to a RAD, a voice mailbox, though I usually just point it to the organization's main auto attendant.

[bioreit]

Thanks Lundah,

Our Mitel support provider came back and advised us to edit any Intercept Number *other* than 1, then under Trunk attributes, trunk Service Number, update the Intercept Number under the relevant SIP trunks to the new Intercept Number above. I guess to simplify rollbacks in case of unintended consequences, although having done a dry-run I think it's actually easier to update intercept #1 and roll it back, than it is to update all the Trunk Attributes on multiple servers.


Once I've had the change approved internally and rolled out, I'll post a quick guide in case anyone else finds it useful.

[johnp]

I just did some intercept routing and find that the destination needs to be defined as it didn't follow forward or reroute to the DN to give Nupoint a mailbox. A Nupoint port with call director worked although I hate to dedicate ports. Looking at RAD on embedded

[bioreit]

@johnp

We're using NuPoint too - all I did was create a dummy extension on one of the MIVBs with Service Level as Full, Class of Service to match a generic SIP phone and Call Rerouting 1st and 2nd Alts as our voicemail number. Creating a corresponding mailbox in NuPoint as normal completed the setup and it works as required when the extension is set as the destination.

[lundah]

@johnp

We're using NuPoint too - all I did was create a dummy extension on one of the MIVBs with Service Level as Full, Class of Service to match a generic SIP phone and Call Rerouting 1st and 2nd Alts as our voicemail number. Creating a corresponding mailbox in NuPoint as normal completed the setup and it works as required when the extension is set as the destination.

Could have made that service level Trusted and not burned a device license, too.

[johnp]

Strange, as what I set up was a trusted extension rerouted to Nupoint with a call director box that played a message then hung up. Pointing a did to it would play this message and hang up but intercept of unassigned to it would end it line group message for the ports. I ended up with some rad ports on the embedded vMCD playing thie message as the only way I could do it with Nupoint was to dedicate a port to it's own line group and intercept to it.

[bioreit]

Could have made that service level Trusted and not burned a device license, too.

Haha, good spot. and thanks!

In case anyone's interested, here's the full run-down of what I did (assuming SIP trunking, MiVoice Business and NuPoint voicemail):

1. On one of the MiVBs create a new extension - Default User and Device:
User Profile
Last Name = something meaningful like NIU Mailbox
Service Profile
Number = Any free number, but I chose one well outside our normal ranges
Service Level = Trusted (thanks again Lundah!)
Service Details
Class of Service = used our CoS for generic SIP devices but as long as it can receive inbound calls and route to voicemail you should be ok
Class of Restriction = as above
DID Service Number = corresponding DID for extension number
Call Rerouting - 1st Alt. = 2 (or whatever routes to your voicemail)
Call Rerouting - 2nd Alt. = as above
Save Changes

In NuPoint, create a new mailbox with the same number as the extension created above.
Give it the same name as the extension (e.g. NIU Mailbox)
Link it to the extension created and set the passcode
Change Class of Service Feature to 6 - GREETING ONLY (or whichever CoS Feature this is for you)
Login to the mailbox and record a suitable greeting

On any shared MiVoice Business instance:
Go to Call routing --> Call Handling --> Intercept Handling
Select the next available Intercept Number (likely to be 2)
Click Change and edit the following:
Directory number out of service - Directory Number = set to extension created on MiVB
Directory number out of service - Tone = change this to blank
Unassigned directory number - Directory Number = set to extension created on MiVB
Unassigned directory number - Tone = change this to blank
Click Save

On each Mitel Border Gateway (as the below is not shared):

Login to the MiVB interface
Go to Trunks --> Trunk Attributes
Identify your inbound SIP Trunk Service Number
Click Change and edit the Intercept Number to the one created in Intercept Handling
Click Save
Repeat on each MBG.


Now any extensions which have issues or don't currently exist but have DID routing enabled, callers will hear the recorded greeting.

The beauty of this is it's global and dynamic - if an extension gets deleted, this will automatically result in subsequent callers hearing the message, rather than just getting reorder tone. If an extension is put into service at a later date, there's no need to manually change anything to stop this message being played - by being put into service it automatically changes that status, as by definition it is neither Out of Service nor Unassigned.