Messages

316

Mitel Software Applications / Re: UCA Client disconnects MBG

« on: December 12, 2012, 11:34:53 AM »

As Nav stated, the UCA softphone (minet)  disconnected (and a clean TCP disconnect, not a network failure).

But this isn't an SSL connection, where did you get that?

317

Mitel Software Applications / Re: one way audio (acd agent)

« on: November 12, 2012, 11:50:25 PM »

i wouldn't think it's a vlan issue, the vlan tagging is done at the device/set level, it has no knowledge of acd/hotdesk  configuration.

it is likely an odd network configuration. he didn't say, do the sets work if they are not logged in to the acd #? logging in can sometimes switch your set to another 3300 and perhaps the network issue lies there..

the only other thing I can think of is a funky setup with SRC... like if it was in a DMZ with external IP addresses. stuff like that can be a bit tricky, but PS can sort that out.

318

Mitel Software Applications / Re: one way audio (acd agent)

« on: November 12, 2012, 02:24:50 PM »

send the tug logs to mitel product support, they can sort out the problem for you.

319

Mitel Software Applications / Re: MBG and 3300 resiliency

« on: August 14, 2012, 04:10:42 AM »

if you've set up 3300 resiliency/clustering correctly, then it should just work.

but make sure you have the ip trunking networking forms on the 3300 set up so they know each other's ip addresses, otherwise they cannot tell the set (and MBG) where to go in case of a failure.

for a set on the lan, they can "cheat" a little bit even if the 3300's are not set up correctly. They can also get resiliency addresses from DHCP and even if the 3300 isn't programmed correctly, they can find the secondary.

A way to test if this kind of misconfiguration is in place, use the '7' key to program a LAN set as a "teleworker", but point it directly at the primary 3300. Then it will not use the DHCP resiliency info. Perform a primary 3300 failure and see if it fails over to the secondary. If it doesn't, then look to the 3300 cluster programming (sorry I can't help you much there).

(you can use the '7' again to remove the teleworker programming on the set afterwards).

there's also a way to see in tug.log if the 3300 is sending the correct 'redirect' information.

320

Mitel Software Applications / Re: Bria Softphone through MBG

« on: August 11, 2012, 08:37:58 AM »

MBG's range of ports hasn't changed in a long while. And you can configure the range in the admin interface, make sure it matches what your firewall is configured to allow (this only applies if you are running MBG in a DMZ).

You are correct, if the f/w has a smaller range then eventually MBG still start using ports that will be blocked... so check and fix!

321

Mitel Software Applications / Re: Bria Softphone through MBG

« on: July 27, 2012, 04:30:55 PM »

MBG doesn't yet support SRTP for SIP devices, so it's not that.

I've had no problems with a number of soft SIP clients connected to MBG, Bria included.

322

Mitel Software Applications / Re: MBG and SIP

« on: June 17, 2012, 05:32:23 PM »

MBG running in Server-Gateway mode or in a DMZ? If the latter, does the DMZ have a SIP-aware ALG running? (it shouldn't).

You've configured your SIP device with the same set-side username and password as your've done on MBG? It's pointing to the right IP?

Try a register and then take a look in the "tug" logs, /var/log/tug.log, these will show how MBG is processing the registration request. You might be able to make sense of it.

323

Mitel MiVoice Business/MCD/3300 / Re: MiNET to SIP conversion 5330 (Mitel SIP Phone)

« on: March 27, 2012, 09:25:29 PM »

Martijn,

I think the simplest thing would be to use the 7 key to put the phone in teleworker mode, pointing it at an MBG running a newish load so the set can tftp new firmware. Once you have new f/w, then you can go through the steps of putting it in SIP mode.

try 216.191.234.113, very new MBG.

Hopefully it isn't too far a jump in versions, that would be my only worry.

324

Mitel Software Applications / Re: New IP on MBG

« on: March 27, 2012, 02:41:12 PM »

Probably the easiest thing to do would be to use the "resiliency" list on MBG to program the new IP address that you will be receiving in the future along with the current IP address of MBG. This will be sent to the sets that connect as "persistent" addresses, IP's to try after a set re-boots.

That way, when you do switch providers, the set will attempt the old address, fail, then try the new address and succeed.

When MBG is moved to the new address, configure the resiliency address to only be the new address.

This is under the clustering->resiliency panel.