How does a global corporation switch to IP Voice? Not so long ago I worked with a company that had more than a dozen offices around the world. Each had its own phone system – a total of five different makes – of which only two could handle IP telephony. As a colleague once put it, we used to “spend a lot of time phoning ourselves”. International calls to our own staff, …
And then when you want UC integration that actually works you will have to upgrade the clients to Lync...
"you wont own the communications network used to transmit the VOIP traffic, so interception is still just as possible as with the ISDN used previously."
As above - use Lync - then you have end to end TLS encryption too.
There isn't always a lot of choice.
In Germany Deutsche Telekom is going 100% VOIP on residential lines this year and all businesses have to migrate by 2018. The reason is, allegedly, that their hardware suppliers are pulling support contracts for the ISDN hardware.
Some cloud telephone exchange providers are offering encryption as well and the system we are installing also supports encryption.
"Unless your company name has 6 letters and means a really really big number, then you wont own the communications network used to transmit the VOIP traffic, so interception is still just as possible as with the ISDN used previously."
I'm sorry, but your WAN is unencrypted between your sites? Someone sitting in the middle can just read all your docs, emails, etc.? Next you'll tell me that you don't have a firewall, and any user on the internet can just connect to your file servers?
What are you talking about? Have you skipped your pills today? In my example my ISDN (the protocol/service I am replacing with VOIP) is encrypted end to end, so when I replace it with VOIP the voice traffic will still be encrypted (possibly using a newer more secure method, but the ISDN was still relatively secure for its time), but the data interception is the same as it has always been, which is what I mentioned in my original post.
So if they could read your secure voice data before they can still read it now, if they can't because it was correctly encrypted they still can't, that was my only point with my comment stating that the interception of the data is just as possible as it was with ISDN, I never mentioned actually being able to use the intercepted data for anything.
"Some countries don't allow VoIP because it by-passes their normal telco snooping."
Which countries? there were a few that people claimed don't allow it but I have held VOIP conferences with people from most of the countries claiming it has been banned.
Dubai, Brazil, Mexico and China are good examples where people claim it is banned but in reality it isn't, at least not for business.
Not quite true,
It's not banned, you're just not allowed to encrypt traffic. Most if not all vendors now have settings for justthis sot of thing. Likewise there are certain places where encryption has to be enabled (GOV for example).
If deploying CISCO you have to be careful with that one as during install it asks about it and if you pick the wrong one, you're fecked further down the line and it's a nuke / start the install again.
D
Actually SIP Connect 1.1 is becoming a globally accepted standard - with liaison work in IETF and SIP Forum. Recently BITKOM (Germany) endorsed this standard. Yes, ISPs still require compliance testing to their own requirements as well, but as this matures there will be much closer alignment to the standard - same road National ISDN traveled back in the 80's. It eventually becomes a cost issue. SIP Connect 2.0 standards are now being developed addressing additional media inter-working concerns.
1. Learn your stuff: SIP is rather complicated and you need to be able to debug it. A quick glance at a pcap of a failed call with Wireshark can turn a week of waiting in vendor hotlines to a 10 minute quick fix.
2. Avoid solutions where you don't get the manual: Those solutions will likely be installed/configured by sales droids with no clue of what they are doing.
3. Plan to swap systems on the fly: 90% of the equipment and software in that are is absolute garbage, 10% kinda work to some degree. There is no correlation of quality and size of the company. So try to keep your systems interoperable and try to have small subsystems.
4. Try to avoid vendor traps: If possible avoid the "unified communications" area. You will be able to replicate most of the functionality with simple soft clients (e.g. Linphone) and voice mail to e-mail.
5. Price does not correlate to quality: There are hugely expensive solutions which simply won't work, but there are cheap solutions which work perfectly fine and reliably. Typically most systems using an Asterisk or Freeswitch server as their core work, or can be made to work with moderate effort, even under highly unusual situations.
6. Avoid "forced certifications": If your vendor demands that only use certified other components/carriers something is fishy. SIP is a complicated protocol, but usually everything just works. Certifications are usually just there to check for that. If your vendor demands certification, it's likely they speak an overly obscure dialect of SIP which will cause problems without end. Good vendors give you free or cheap methods to try out your setup before you finally commit.
If you act sensibly and avoid the traps you will end up with a system which can grow and adapt to the needs of your organisation. If you just buy the "unified" solution from your large "trustworthy partner" you will end up with a pile of toxic waste troubling you even further than web applications built for IE6. (yes 2 of the "avoid at all cost" companies have been mentioned in the article)
Hi Dave,
Can you clarify something for me...."The Mitel systems were hooked together using Mitel's proprietary protocols, mainly because Mitel SIP trunk licences cost the thick end of £50 per channel and we would need several dozen channels, while Mitel-proprietary voice over IP (VoIP) trunks cost nothing."
When you say "..per channel.." do you mean: 1) SIP Session, 2) PRI Channel (1 of 23/24) or 3) a complete trunk (24 / 32 channels)?
Seriously, if you have to ask that question, you should re-consider your decision for that product. On state of the art products such trunks shouldn't cost anything.
The probable reason they cost something is that the PBX doesn't speak normal SIP, but some sort of rather odd dialect of it which probably even requires quite a lot of configuration to get it running enough so the customer lets you go home.
We have at least one customers who has such a "big vendor" system which the vendor couldn't get running. They switched VAR and got one to install a custom Asterisk-Server which would translate between their really weird SIP and normal SIP.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
