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 - mattybrownuk

Pages: [1] 2 3
1
Thanks guys

I wonder if I modify the value using Online Monitor on a single handset, would I then be able to copy the settings from one phone to another, or would I have to manually edit each phone?

Very odd that the ringtone has been altered by a firmware update.  We've updated ours annually since 2013 and it's never changed the ringtone.

Thanks,
Matty.

2
Hi

We updated our MiVoice Office 250 to 6.3 (SP7) over the Christmas break and have found that all of our handsets now have a different ring tone.

I can't see any mention of this in the release notes.  I know I could go to each handset and use the "Ring Tone Selection" feature code to change the ring type from 1 to 2 on each phone individually, but that's time consuming... there must be a way of changing it from DB Programming?

Thanks,
Matty.

3
We've ported our numbers from our old ISDN30 circuit over to SIP trunks, so the ISDN30's PRI module now needs decommissioning in programming.

The phone system has been complaining of "A114 ALARM Dual T1/E1/PRI Module (T1M-2) 1 Port 2 In Red Alarm" since shortly after the number port had completed.

What needs changing to prevent alerts and properly decommission the PRI module?

Also, when a new extension is created, it's still defaulting to the ISDN30 trunk group number.  Where is this default set?

Thanks,
Matty Brown

4
SIP Trunk Groups\82002\Configuration\IP Address had been set to the provider's IP address.  Once this had been changed back to the default value, 255.255.255.255 INVITE's started to succeed.

Our SIP Trunk provider's instructions said "IP Address: Configure the IP address.", which should have probably read, "IP Address: Leave as default, 255.255.255.255".  I went through the configuration guide over and over before realising that the INVITE messages had the SIP Trunk provider's IP address listed, but not our FQDN.

I now have incoming and outgoing calls working.  Thanks for your help, TE.

5
Hi TE,

Thanks for your help.  Much appreciated.

So today, the supplier has "made some changes on the SIP Trunk on the platform" and now all the incoming DDI numbers are working!!

Still can't make outgoing calls, but we're one step closer.

Are you sure that they are allowing outbound calls to Out of Network phone numbers? Meaning do they allow calls going to another Carrier? Try calling a number that is In-Network and see if you have the same issue.
Outbound calls certainly should be allowed... I can only assume that they've configured the service correctly their end!  Now I know all ten DDI's are working, I tried calling outbound to one of the other DDI numbers, but that fails the came as calling my mobile number.

Also, you may also want to make sure that the Firewall/Router is not performing some sort of Transformation on your SIP messages.
Our firewall is a FortiGate 100E and I just noticed that the VoIP feature is disabled... maybe the issue is that the firewall should be swapping out our private IP address with the public IP address, but the whole feature in general is disabled?  It's a managed firewall... managed by the same company that's providing the SIP Trunks and I don't have the rights needed to enable the feature myself.  I'll mention it to them tomorrow.

The other thing I would try, like you stated, is making sure the 44 is in front of the dialed numbered. I noticed that you didn't put the 0 when you showed it with the 44 in front of it so my guess is that a leading 0 is only allowed when the country code isn't on there?

If you want to test that out then just setup a new Facility Group that removes the 07 and puts in the 447 into the dialed digits. Then use that Facility Group in a new Route Group that looks for your test number to be dialed out. For testing purposes you can set this to Route 1 since it should only work for a specific number being dialed. Don't leave this new Route Group at 1 though when you are done testing as that is the route that is used for Emergency calls. If you know which Route Group it would normally take then put it right before that one instead of Route 1.
I don't understand how Facility/Route Groups work and find a good explanation online, so I'm not going to touch it!  If the SIP Trunk provider tells me the issue is due to the format of the number being dialled, I'll ask the phone system maintainer to get involved again.

Thanks again for your input!  :D

6
Hi TE, thanks for getting back to me.

mattybrownuk,

It looks as though the user you are acting as is not a valid user.
Could be - I actually don't have any "employees" created in the Hosted Voice portal.  Since these are trunks for use by any extensions that attempt to make a phone call, they're not specific to any one employee, so I don't even understand why I have that option in their portal.

If I had to guess the phone number being used is not one provided by the SIP Carrier, but one provided by your ISDN30 Carrier; 441912345789.
The real phone number in this capture is one from the SIP carrier, not the ISDN30 - they gave us 10 temporary DDI numbers to test with.  I've swapped out the number in this packet capture for a fake number formatted like a real one, so there's no identifiable info.

I am not familiar with how the Numbering Plan works in the UK, but is this a valid phone number; 07123456789? The other issue you may is if they require E.164 as you are not sending calls out using that.
Yes, numbers with the format 07xxxxxxxxx are valid UK mobile numbers.  I'm wondering whether the SIP provider is expecting the leading 0 to be 44 (UK country code), like 447xxxxxxxxx.  I've no idea where to change that to try it.
The configuration guide says "Use ITU-T E.164 Phone Number: If set to Yes, the MiVo250 handles ITU-T E.164 formatted phone numbers as part of the incoming SIP INVITE messages from the SIP peer. Set this to NO for WHC.", so no, they don't require E.164.

7
We're in the UK, currently using ISDN30 to make and receive calls on our MiVoice Office 250.

We're attempting to switch a limited number of phones over to making their outgoing calls via 5 SIP Trunks so that we can trial making and receiving calls via SIP before increasing that to 20 SIP trunks, moving all outgoing calls to SIP Trunks and eventually porting over all of our incoming numbers and disconnecting the ISDN30.

We have:
  • Subscribed to a BT WHC (Wholesale Hosted Communications) provider (5 SIP trunks + 10 temporary DDI's)
  • Added 5 SIP Trunk licenses to our PBX
  • Had the company that looks after our Mitel PBX configure it for us using the SIP Device Configuration Guide, May 2019

And now:
  • We can make incoming calls to the first number in the block of 10 DDI's
  • We cannot receive any incoming calls to the other 9 numbers in that block
  • We cannot make any outgoing calls

When attempting to make an outgoing call, I can see from the packet capture on our firewall that we're getting a 404 User not Found response, but I don't know whether that means the number dialled should have started with the country code 44 instead of 0 (and how to fix that, if that's the problem) or whether this means there's a configuration problem at BT's end, or some other reason entirely why this isn't working.

I also have no clue as to why our system is only receiving calls for the first trunk number and not the other 9... they're not programmed anywhere in our PBX other than the Call Routing Table - I presumed that when our system registers for the first trunk number, that automatically routes all the numbers on our account to us... is that not the case?

Hope someone can make sense of this?  :):

Quote
INVITE sip:07123456789@62.7.201.169:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.144.2:5060;branch=z9hG4bK2392623975-949
Route: <sip:62.7.201.169:5060;lr>
Max-Forwards: 70
Allow: NOTIFY,REGISTER,REFER,SUBSCRIBE,INFO,INVITE,ACK,OPTIONS,CANCEL,BYE
User-Agent: Mitel-5000-ICP-6.3.7.99
P-Asserted-Identity: "Our Company Name" <sip:441912345789@62.7.201.169>
From: "Our Company Name" <sip:441912345789@62.7.201.169:5060>;tag=Mitel-5000_2392624714-949
To: 07123456789 <sip:07123456789@62.7.201.169:5060>
Call-ID: 2392620560-949
CSeq: 1 INVITE
Contact: "Our Company Name" <sip:441912345789@192.168.144.2:5060>
Content-Type: application/sdp
Content-Length: 297

v=0
o=Mitel-5000-ICP 1091902712 1604593585 IN IP4 192.168.144.2
s=SIP Call
c=IN IP4 192.168.144.2
t=0 0
m=audio 6014 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:30
a=sqn:0
a=cdsc:1 image udptl t38
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.144.2:5060;branch=z9hG4bK2392623975-949
From: "Our Company Name" <sip:441912345789@62.7.201.169:5060>;tag=Mitel-5000_2392624714-949
To: 07123456789 <sip:07123456789@62.7.201.169:5060>
Call-ID: 2392620560-949
CSeq: 1 INVITE
Content-Length: 0

SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.144.2:5060;branch=z9hG4bK2392623975-949
To: 07123456789 <sip:07123456789@62.7.201.169>;tag=3813582385-232866451
From: "Our Company Name" <sip:441912345789@62.7.201.169>;tag=Mitel-5000_2392624714-949
Call-ID: 2392620560-949
CSeq: 1 INVITE
Allow: PUBLISH,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Contact: <sip:07123456789@62.7.201.169:5060>
Reason: Q.850;cause=1;text="User not Found"
Content-Length: 0

ACK sip:07123456789@62.7.201.169:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.144.2:5060;branch=z9hG4bK2392623975-949
Route: <sip:62.7.201.169:5060;lr>
Max-Forwards: 70
From: "Our Company Name" <sip:441912345789@62.7.201.169:5060>;tag=Mitel-5000_2392624714-949
To: 07123456789 <sip:07123456789@62.7.201.169:5060>;tag=3813582385-232866451
Call-ID: 2392620560-949
CSeq: 1 ACK
Contact: "Our Company Name" <sip:441912345789@192.168.144.2:5060>
Content-Length: 0

8
It's coming up to another bank holiday and as usual, our phone system is going to be in Day Mode all day even though the company is closed thanks to the MiVoice Office Application Suite's Night Service feature not supporting the ability to skip dates or date ranges.

Sure, we could temporarily disable the Night Service feature in MiVo OAS over the weekend (and remember to re-enable it the following Tuesday), but why should we have to?

It also doesn't appear to support weekends very well as you have to enter a start and end time for 7 days of the week, so we have ours toggle Night mode for one minute on a Saturday and Sunday morning around 2am to get around it.

We had a STAR application at one point, but that messes with the call records, since the STAR application technically answers the call so hey presto, no more missed calls, or so it would appear in the TIM Plus reports!

What does everyone else do?  Would anyone else like to see the Night Service feature improved upon?

Cheers,
Matty Brown

9
If you are familiar with debian and iptables you can ssh into the system and open the ports via command to specified public. This would typically only work if all the offsite phones have static address's on their end.

Can't say I am familiar with debian and iptables, no.  But none of our staff working remotely (me included) have static IP addresses, unsurprisingly.

I am a bit concerned about setting up port forwarding from our public IP to our phone system - especially as the client end has to be left open to any IPv4 address, but less so than I was, now I know this is the way plenty of others do it and it hasn't caused you guys issues.

10
You will be forwarding a specific set of ports directly to the phone system, literally tens of thousands of systems are setup this way... There is no appreciable security concern as long as it's done properly.

I usually tell customers, depending on their Internet connection, that 4-6 phones remotely via port forwarding is fine, much more than that needs an MBG. That said, I have customers with 20+ phones remotely via port forwarding and zero issues. I have never seen, nor heard from another tech anywhere (and I talk to a lot of them), of a security breach via a remote MiNet phone or it's connection.

What exactly does an MBG give you over port forwarding? Capacity, management, some level of security
Is port forwarding as insecure as it sounds? No, there are no appreciable security concerns with MiNet phones (SIP is a different story though)

I did port forwarding for about seven years with close to twenty phones and never had an issue with security or performance. Make sure you only forward the ports you need and keep you're phone system semi-current, and you'll be fine

I have also been opening the ports for remote phones that use minet without a single issue... ever.

Thanks for the advice guys, much appreciated.

11
Is there a dongle key for this set? Heard this works better in other apps and fixes issues

The Jabra Evolve 65 comes with a Jabra Link 370 USB dongle, which is a bluetooth dongle specifically for use with their headsets with an LED indicator on it to tell you what mode it's in, etc.

The reliability of it is great... but the mono, voice quality audio you get out of the headphones whenever Mitel PM has the microphone is poor, because of the "voice link" mode feature.

12
We currently use Mitel Phone Manager as a softphone for all of our remote workers, which has worked well so far, connecting via an SSL VPN client on the user's PC back to our corporate network, where our MiVoice Office 250 is.

I've been asked if it's possible to connect a physical Mitel 5330e handset remotely, over the Internet and I'm told it is, but I have my concerns over how secure that would be.  Having the softphones connect in via a secure VPN tunnel seems much safer, but it's hard to see how I could get a desk phone connected as securely.

I'm told that I don't need to use Mitel Border Gateway (MBG) - I can just forward a number of TCP and UDP ports from our public IP address to our phone system, boot the phones up whilst holding 7, input our public IP address and the phones will connect as if they're onsite.  But that doesn't sound very secure to me - especially given the easily guessed default PIN numbers for extensions.

What would MBG give me, over and above what could be accomplished by port forwarding?  Is port forwarding really as insecure as it sounds?

13
Our supplier has reproduced the issue with a headset by Plantronics.  Again, sound quality outside of calls whenever Mitel Phone Manager has the microphone is poor.

A case has been raised with Mitel ref SUP187400.

14
We've recently started using Mitel Phone Manager as a Softphone client, to enable people to work from home.

We've been using the Jabra Evolve 40 USB headset, which works very well.

I've gone on to to try a Jabra Evolve 65 headset, which is a bluetooth headset that looks almost identical to the Jabra Evolve 40.  It works very well during calls, but I've noticed that it's dropping into "Voice link" mode whenever an application grabs the microphone.  When it's not in "voice link" mode, the sound quality is great.  The moment I start Phone Manager, it changes from Stereo to Mono and drops the quality.  It makes music or anything other than voice sound like an old gramophone, complete with crackling sound for anything above a certain volume!

Applications like Teams or Voice Recorder only grab the mic when they need to, but I've found out that Mitel Phone Manager grabs it constantly, as soon as it connects as a Softphone/SIP client.

Does anyone know how to report this issue to Mitel or Xarios?  Seems like a bug to me and limits the functionality of the headset which otherwise works very well.

I realise that the headsets I've chosen aren't on Mitel/Xarios's compatibility list so they may not be keen to make changes, but it's worth a shot... besides, having the microphone icon at the bottom right of the screen to show you're being listened to even when you're not on a call may be of concern to some!

Thanks,
Matty Brown.

15
After further review, I have verified that removing Security Update for Microsoft Office 2010 (KB4484127) 32-Bit Edition resolves the problem.  Good luck to anyone else who runs into this specific issue.

Thanks for the tip - I was concerned our database might have been corrupted.  Thankfully it looks okay and I've taken a fresh backup.

Pages: [1] 2 3