Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bioreit

Pages: [1]
1
Is it safe to assume that internal calls to the ring group don't get put on hold? And that direct internal and external calls to the softphones are also both ok? That it's only external calls to a ring group answered by a softphone which can get put on hold and can't be resumed?

It would potentially be worth exploring the codecs being used; I've not seen a call auto-hold or refuse to be resumed before, but I've had a lot of weird stuff happen when there's a codec mismatch, particularly when a call passes through external to internal via another hop (Ring Group, Attendant, Call transfer).
Just had a thought on this:
On the MiVBs, go to System Options and check the Number of Forward Hops. If it's too low then calls might get dropped after working their way to the softphones? Kind of doubt it would present in that way with a call being ghost-held rather than just dropping completely, but worth checking. We have ours set to 4 but think the default is 2?


BIG CAVEAT HERE: if you're not sure/familiar with changing the settings I'm referencing below, definitely don't poke first! If you must poke them, keep a detailed log of what you're changing and try to only change one or two things at once, test, then restore immediately if unsuccessful.

In MiCollab, go to:

Applications --> MiCollab Client Deployment

Across the top click on Deployment Profiles and select the edit pencil next to the profile being used

Scroll down to Softphone Settings and verify the Default audio codec in both 'columns' - PBX type and Teleworker type. (ours is set to Standard EU (G.711 A-law)


On your SIP MBG(s) go to:

Applications --> MiVoice Border Gateway

Across the top click System and then Settings

Under both the MiNet options and SIP options sections, make sure that Codec support has the MiCollab codec listed.


While you're checking both, would also be worth verifying everything else is consistent, RTP or SRTP mode, SIP transport protocol (TLS, TCP/PSK), etc.

Would also say

SIP MBG(s): under MiNet options and SIP options check if you're using Device <-> device local streaming and/or device <-> trunk local streaming. We don't use either but this will depend on how you have things setup so if you're using them that's not necessarily bad (and if you're not using them then that's not necessarily bad either).

MiCollab: under Softphone Settings check the SIP DTMF method is correct. Verify against the MiVB SIP Device Capabilities used by your softphone clients under Signaling and Header Manipulation (CoS 64 for us)


Lastly, on the MiVoice Business: Check the SIP Device Capabilities settings, particularly SDP Options and Signaling and Header Manipulation. Particularly M-Lines and Media Renegotiation/Codec entries.

Also on the MiVBs: Check Class of Service for the Ring Groups (verify the specific CoS assigned to one or more of the known-affected groups first - been bitten before when a colleague mis-assigned the incorrect CoS to a group!). There are loads of options here, so if nothing leaps out and you're not sure, feel free to paste all the CoS settings you have under General and Advanced and I can take a look at some point.

2
Thought I'd report back that this is now fixed; after many weeks of head-meets-desk, turns out that really all that needed changing was disabling RTP Collision Detection under Network Settings on the RFP 12 base station.

Thing is, this setting had definitely been changed in earlier attempts, so all I can assume is that another changed setting somewhere was interfering - by starting again from scratch and disabling only that setting, the issue is resolved. But to muddy the waters, changing other settings under Network or Servers doesn't seem to break any of the phones again, so it's a bit of a mystery!

3
Hey guys,

We have a situation where some of ours are having issues with internal calls.  A user will call a coworker, the phone rings and when answered there's no sound on each end.  What configurations could be put in place to diagnose this situation?

thanks!

What's the phone model? We had a few faulty 6930 units - some had no audio when using the receiver, others would have no audio when using a headset, a couple would have no audio over speaker. That was 100% of the time though, rather than intermittent - but intermittency like that implies a local hardware failure to me.

If you can, I'd be tempted to swap out the 'problem' phone with another known-working phone in a completely different area - if the fault follows the phone, it's broken and either repair or send it to live on a nice farm somewhere. If the fault stays with the user, it's a networking issue (or the user - had one who kept yanking the curly cord straight while on the phone, then complaining of crackling....). Also might be worth swapping out the curly cord and receiver for a known-working one first, in case those have somehow died.

4
Hi all,

This is a really weird one. We have Mitel 112 DECT phones, connecting via RFP 12 base stations - not loads, just a few, but as is typical they're some of the more important users! We've found that when external callers dial in (either to our Attendant consoles or a Mitel 6930) and are then internally transferred to these DECT phones, we end up with one-way audio - the DECT user cannot hear the original caller.

If an Attendant console or 6930 does an attended transfer, then the audio is fine until the transfer is completed, then it's one-way.

If they start an ad-hoc conference and all three parties are present, then audio is fine. As soon as the original destination drops out, leaving the caller and the DECT phone, audio becomes one-way.

Testing has revealed the same is true if an external caller dials a DECT phone directly and is then placed on hold - when brought off hold the audio becomes one-way when previously it was working fine.

If the call is transferred to the DECT phone via its DID number, then two-way audio is fine (unless it's placed on hold....).

Causes potentially ruled out:
Class of Service - we have other phones in use as Generic SIP with the same Cos which don't experience the issue
SIP Device Capabilities - as above, other phones using the same don't have the issue. Also checked other settings to make sure there wasn't anything obviously incorrect, couldn't see anything (doesn't mean I didn't miss it though!)
Firewall - nothing on the firewall to indicate traffic being dropped or blocked. Ports reported by all connected devices as being used in calls are in the firewall as permitted for those IP ranges
RFP 12 Settings - Checked Hold Behaviour, DTMF Signalling, Codecs, SIP Ports and ToS/QoS (tried every possible combination, apart from ToS/QoS - far too many for that!)
SIP Trunk MiVB - SIP Peer Profile tried various changes under SDP Options and Signaling and Header Manipulation


All reported to our support provider but they're equally as stumped!


It did all seem to suggest to me that this is a codec negotiation issue, or similar:
A calls B, negotiates a codec. B initiates transfer to C potentially with another codec, completes the transfer joining A and C.
A is communicating on the codec negotiated with B, C is communicating on the (different) codec negotiated with B, one-way audio results.
Seeing as A <--> C works fine if B uses C's DID to transfer, I guess because the MBG is involved it is renegotiating the codec correctly between A and C? Or is this me barking up the wrong tree?
Tried removing all codecs from the DECT apart from G711A (packet captures point to this as the codec negotiated in all conversations) but didn't improve matters. So perhaps I am getting (wrongly) fixated on that as a potential cause...


Any random ideas gratefully received!



Setup:
MiVoice Business, Active Embedded 3300 v 14.0.1.29, MiVoice Business Blade v 8.0.1.25, running MSL 10.5.19.0
MiCollab 8.0.0.40 using flow-through provisioning for Hot Desk users, remainder such as DECT created on MiVBs as Generic SIP
MBG 10.0.0.116, MSL version 10.5.19.0
SIP Trunking to MiVB servers
RFP 12 Base Station Firmware:    IPDECT/03.55/B0007/23-Oct-2015 11:24

Hot Desk users: Mitel 6930
Generic SIP: Mitel 112 DECT, Aastra 6731i, a few other random types

5
Mitel MiVoice Business/MCD/3300 / Re: Non-Existent DNs - Play Message?
« on: October 27, 2020, 07:00:28 AM »

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.



6
Mitel MiVoice Business/MCD/3300 / Re: Non-Existent DNs - Play Message?
« on: October 22, 2020, 06:01:23 AM »
@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.

7
Mitel MiVoice Business/MCD/3300 / Re: Non-Existent DNs - Play Message?
« on: October 20, 2020, 06:21:19 AM »
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.

8
Mitel MiVoice Business/MCD/3300 / Re: Non-Existent DNs - Play Message?
« on: October 14, 2020, 04:28:51 AM »
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!

9
Mitel MiVoice Business/MCD/3300 / Non-Existent DNs - Play Message?
« on: October 13, 2020, 12:24:01 PM »
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.

10
Hi guys,

Just wondering if anybody knows of a way to get a Mitel system (MiVB and MiCollab) to somehow match an incoming caller ID number and display a corresponding name for the caller on the sets or MiCollab client?

This is for incoming calls via a SIP trunk.

I've tried adding a contact to the phone with the caller number, but it doesn't display the name on the screen when that number calls.

Thanks.

Was going to ask a similar question - we have 6930IP handsets and a 3300 system we're about to roll-out and have found that adding an external contact into Personal Contacts is really only useful for our users when they want to make an outbound call to that number; for inbound calls from a Personal Contact, it just shows the number twice, instead of the number and the saved name. You can't add Alpha Tagging to the Personal Contact entries as you can't get the ~ character via the handset, and in Micollab it doesn't seem to integrate fully with the phone, as Personal Contacts saved on the phone don't appear in MiCollab (nor vice versa). And even if it did, you can't Alpha Tag in MiCollab because adding a ~ causes the 'OK' box out to grey out so you can't click it.

Seems like the only way to get this working is get our several thousand users to tell us every time they add/delete/change a Personal Contact, so we can add it into the Telephone Directory form with the necessary Alpha Tagging. I'm sure the support requests will calm down once everyone is sorted, but the first few weeks of this are going to be hell, particularly as our previous system used a kind of local inbound caller ID for any personally saved contacts - so our users are not going to be very happy with a backwards-step!

Oh well, we'll just add it to the list of feature requests we're sending to Mitel! :-)

11
Using MiCollab Client to forward all your calls takes a couple clicks.

Agreed. As long as they've set it all up correctly in the first place - when they haven't, it *is* convoluted compared to our current offering: three clicks and one instance of typing, versus 14 clicks and three instances of typing.

It can't possibly be more complicated than a bodged-together Asterix web-portal.

Yes, MiCollab is more complicated - when users need to setup a call divert to a new destination in a hurry, which is the scenario I was hoping to find a solution for. We invested the time and effort in creating the portal to make our users' lives easier, as to us that is more important than making *our* lives easier; if you have different priorities, that's fine - for you.

And the benefit of the MiCollab client is that 99% of users have standard configurations they return to, so they don't have to reconfigure their Call Forwarding destination every time they want to activate it - in fact the vast majority of our users rarely even use call forwarding seeing as the MDUG functionality is so convenient for them.

Again, agreed, but we are not rolling out MiCollab due to an internal decision as it would cause too much confusion and conflict with programs we already have, which integrate with our other requirements much better and fit into our culture more completely. Granted, that's *our* issue and *our* decision, but it's the one which has been made and spurred my asking the initial question of whether there was another way. There isn't, that's fine, I accept that.

No end-user I've spoken to has ever described MiCollab Client as "convoluted". And I have thousands of them. It is a powerful and intuitive piece of software.

That's great. We have thousands of users too and of the proportion of those who have seen the suite of products we have, all bar one says it's much more convoluted than our current setup.

All change is painful and this one seems like it will be particularly so - but like I said before, I'm sure we will get there and I'm sure people will learn to live with it and I'm even sure that most will come to prefer the Mitel solution. It's just we are trying to make the transition to Mitel as smooth as possible for our users and this was one question which, if answered, could have helped that process a great deal. But I accept that it can't be done.

12
You're going to find the Mitel way a bit of a culture shock if you're used to a product you can tinker with and customise to your requirements.

Yeah, we're finding that out - we kind of had to move away from our current Asterisk solution but we perhaps naively assumed that a phone system would do roughly similar things in the same ways, which to a certain extent it does I guess, it's just not necessarily the perfect fit for our requirements. Plus, some of our decision-makers were definitely awed by some sales pitches which never really matched the reality (quelle surprise!). But I'm sure we can make it work well enough.

13
I think it's quite funny that you call the idea of simply using the MiCollab Client "convoluted" and then you come up with a plan involving building a web portal and poking commands into bits of the Mitel applications to achieve what is done so very simply from the MiCollab client.
 
Using the MiCollab Client, users initially simply create statuses reflecting how they want their Multi-Device User Group to behave, eg,
An "In the office" status that rings their deskphone
A "Working from Home" status that rings their softphone
An "On the Road" status that rings their mobile AND softphone
An "In a meeting" status that rings their voicemail
A "Send everything to Bob" status that sends all their calls to Bob
etc....
This is a one-time config to create each status, unlike call forwarding where you have to reconfigure the target number for each different scenario every single time

Then all they have to do in the MiCollab Client is flick between statuses according to need. They can run the client on their desktop/laptop or mobile.
 
Also, they can configure their Client to use their Outlook calendar statuses to change their MiCollab status automatically, eg,
"Busy" - change MiCollab to "In a Meeting"
"Out of Office" --> "Send Everything to Rob"
"Working Elsewhere" --> "On the Road".

Yes, MiCollab is convoluted - for the end-user. All of the options you listed above are perfectly valid, but presume that our users have set those up ahead of time. The self-service portal was a bit convoluted for us to setup initially, in that it took literally three hours of coding and testing and from then on we never needed to get involved ever again, and our users could add, change, remove call forward destinations by clicking on a single link and entering a number. Compared to that MiCollab is *extremely* convoluted, if they get to a meeting and realise that the call forwarding destination they have configured to send calls to their colleague won't work, because that person has called in sick - now they need to login to the MiCollab client and add a new destination and/or create a new status, then change to that status. And changing those numbers is many more clicks and menu options away than our existing offering, which would not only require us to provide more training, but will lead to more support tickets and will also lead to greater user frustration.

Consider it from our users point of view - previously, to divert their phone to any number or extension, they just clicked on a link, typed in a number and hit submit (ignoring their ability to also do this from phones - this portal is more for the "Oh crap, I totally forgot to divert my phone before leaving the office" situations). Now we're having to say "Oh, we've changed all that - now all you need to do is log into this app, click on Settings, click on My Numbers, click the ellipsis at the top right, click +New, add in a label, add in the number, Click Add, then click on Manage Status, then click on the ellipsis at the top right of *that* pane, click +New, enter a Status Name, change Send my calls to [the number you just typed in], then click Done. THEN, all you have to do is change to that status whenever you want to divert to that number. It's really simple really and so much better than the old system and who cares if you had to spend five minutes in that meeting you were already late for because it's sooo much better"

I was only asking because we've been able to come up with a simple method for our users to reset their passcodes - which there is literally no 'Mitel' way of doing without knowing the previous passcode, which kind of defeats the object because that's the main reason people would need to reset them - so was wondering if there was a similar function we could hook into to replicate our existing end-user approved system. And FYI, that user-passcode reset portal did take more effort - nearly a whole morning to put in place!

But this is clearly a system limitation of Mitel coupled with our pre-existing applications rendering what is clearly a core component (MiCollab) redundant, so we'll just have to put up with it I guess.

Thanks for responses, even if they were a bit unnecessarily condescending and completely ignored the fact we're not rolling MiCollab out...

14
Hi,

I was wondering if there was a command line...command... which can change the Call Rerouting Always destinations on a per extension basis? For example, is there a command which can do "For extension 1234, set Call Forwarding Always Destination to {EXTENSION} or {MOBILE NUMBER} and Enable"?

For a bit of context, we're very new to Mitel (still being built by our suppliers!) and coming from a self-designed and self-supported Asterisk system. All of our users are Hot Desking Users on Mitel 6930 IP handsets, we have MiVoice Business 8.0 SP1 and MiCollab (v8.0.0.40, MSL v10.5.21) servers installed but we are not using the MiCollab client for various reasons - clunky interface for one, most other functionality is better-provided through other applications we already use - but we would very much like to be able to replicate functionality from our Asterisk system, namely a web-based self-service portal which lets users divert their extension to a mobile or other extension very simply.

Because we're not using MiCollab, our suppliers have said the only way to do this is from the phones themselves, changing the Call Forward Always number in the Settings and enabling (we do have a softkey already configured in the templates for Divert On/Off so once configured with a destination that's pretty easy), but the issue we have with this option is that it requires the user to be in front of a phone; our users have become familiar with the ability to get to an off-site meeting, discover they have forgotten to divert their phone to a mobile or a colleague, and can just login to the self-service portal and type a destination into a box and hit Save (we did explore using MiCollab just for this purpose but it is so convoluted in comparison, it would cause more issues than if we just asked users to call us to do it on their behalf!).

So, is there a command which can do this function on behalf of users? I have already discovered the asetpass m1=mailbox pw=passcode command in NuPoint for changing mailbox passcodes (which synchronises to our Hot Desk passcodes), so we can provide a self-service tool for our users to reset their own passcodes without calling the support team, by creating a web front-end over a script which calls up that function - which is another feature of our Asterisk portal we wanted to keep - but I can't find a similar one for MiVoice Business / MiCollab.

Any help would be greatly appreciated - even a definitive answer on whether this is just one of those features we're going to have to lose by transitioning over!

Bioreit

Pages: [1]