We have a Mitel VoIP telephone system. It’s a 3310 ICP and uses proprietary everything. I guess some parts support SIP, but I haven’t really tried to screw it up yet. The phones boot up the boot code, DHCP,get the server from the dhcp options, then TFTP an image if needed and boot then boot the main code. The protocol is called MiNET and it’s supposedly encrypted. I have to assume they do the standard pki encrypted exchange of a session key, as there’s nothing in the happy web front ends about all of this.
However, the phones don’t work out of the box if you start taking them outside the network. The ICP has an internal IP address for starts. I don’t know anything about MiNET so I don’t know if it’s got the fatal SIP header flaw with NATs or the whatnot. but the magic key is this Mitel 6000 “MAS” box that runs the “teleworker solution”. If I put the phone in teleworker mode and give it the IP of this box, the phones work almost anywhere. The box runs linux, and I have a heard time telling from the outside what it really does. I thought about emailing the developer, but figured he wouldn’t appreciate a support request.
So I emailed our vendor. I got a couple of “well, it makes the phones work outside the network responses” and then finally talked to someone today, but they weren’t very impressed that they had to call me when I didn’t really have a problem. So I asked why I needed the teleworker solution and the first explanation was that the ICP had a private address and had no provision for another address.
“So the teleworker solution just does NAT?”
“Yeah.”
“Really? That’s kind of a big box.” (it’s a mid-tower case)
“Physically or performance wise.”
“Well, both, but I meant performance.”
“Well it has specific requirements, it does compression.”
I get into a conversation about transcoding and imply that now it’s not a NAT box, it’s a proxy. The conversation stars going down hill. I explained I just wanted to know because I had a couple wierd problems that I couldn’t troubleshoot, having to assume that the phone, teleworker, and voip pbx were simply magic. He then “let me know” how to configure the phone to use the teleworker. I explained I got that and he stops and says, “So what can I help you with?”. “Well then. I guess we’re all set.”
I hate technology people that aren’t geeks. I’m sure imaging the box, clearing the root pw and playing around is “reverse engineering” and I lose my warranty or ‘support’ at best, or get sent to a prision in russia somewhere that doesn’t exist at worst.
My only question left. It’s not just using MAC Authentication, right? I mean, I know it’s closed source and all that, but… That developer guy looks smarter than that. I’ll ponder that possibly giant security gap for a while.
Thanks for the reply Lee!
Obviously it helps a lot on the troubleshooting side of things to know that there’s a daemon there doing something productive.
My other question is about how the teleworker solution handles tftp. Do the phones use a different boot or main code line when in teleworker mode that they download from the teleworker pc, or does it proxy the tftp connection back to the ICP? I had a couple wierd issues with teleworker phones getting sporadic “L2” boot errors, that seem to have gone away, but sparked my research into what the box really did.
I am having the same problem i have a teleworker phone in Hong Kong and it gets an L2 boot error. What can you tell me to do to allow the phone to download it’s conf?
@Mae,
This was years ago that I worked with this. I don’t recall anything additional about the problem beyond what’s in my above comment. Sorry.