OCS 2007 and 3CX Integration

[danieldo]

I am having issues with Microsoft OCS 2007 where the service expects the tel uri to be in the e.164 format with +<number>. The 3CX doesn't doesn't like the use of the + and OCS 2007 requires it for reverse number lookup to a user account. I tried replacing the + with a '00' but no joy.

13:18:41.946|.\Endpoint.cpp(197)|Critical0|Endpoint|Endpoint::findSource:[CM010001] Line configuration does not allow identification of the source of this call. Check Advanced Options for Gateways and Providers and match a field to a correct value from the following: Contact IP: 'UMOCSMED.UM.LOCAL'; From: '+243'; To: '235'; Rline: '235'; Contact:

The 3CX version is 3.1.2434.0. Is there any way to get the two systems talking?

 

[jasonshave]

Is there an update to allowing a "+" sign in the web interface?

Could someone point me in the direction of possibly modifying a file to allow this? I really would like to have my OCS environment working!!!

 

[N_G]

I think OCS will require more then just the + functionality.

OCS is almost completely proprietary. It simply does not work like other SIP trunking providers and requires a completely new type of SIP trunk. It doesnt do authentication according to SIP RFC, it has its own proprietary codec, its own addressing and so on. It also wants to work on TCP only and does not negiotiate to TCP, just doesnt answer if its not on TCP. Its completely proprietary and advertises this as a strong point. (?)

We think customers want to work with solutions that follow the SIP RFC. Getting locked into to another proprietary standard of Microsoft doesnt make sense and its not a path we want to join Microsoft on. That said, i am hearing sounds from various blogs that Microsoft might be considering making OCS somewhat easier to integrate with and less proprietary.

We have not ruled out OCS integration in the future, but right now its not a market we are focusing on.

Meanwhile, if you need a corporate chat server, why not use something like Openfire (runs on Windows, open source) or Interactive NI (windows, good solution not expensive)?

 

[moon1234]

Hi Nick,

TCP is actually required to be in full compliance with the RFC's. UDP is optional. So in a sense you could say 3CX is not in full complaince with the RFC's. I think where there is a disconnect between OCS and 3CX is the target demographic. OCS is targeting enterprise customers who want a unified experience across all of Microsoft's products and across the entire communications platform. TCP was chosen becuase of it's superior packet performance across VPN's, the internet and disperate networks in general.

OCS's codec is Microsoft's RTP voice codec. I think it is debatable whether it is any more propriatary as the RFC's do not limit the codec choice. G.711, G.726, G.729, iLBC, GSM, etc. are all different codecs that are commonly used in different SIP implementations. Just because OCS does not support them all does not mean it is somehow limited as a SIP server. Microsoft is using a codec that is supposed to be able to dynamically fallback to lower bitrates or increase to a higher bitrate as network conditions change. The is supposed to help remove one of the common problems people experience when using RTP over slower or unstable network links (VPN, Cellular, dialup, etc.). As far as I know, none of the other codecs offer dynamic changes like this while a conversation is happening.

OCS also has full support for strong encryption. Many corporations have a problem with running unencrypted, connectionless protocols on their networks. I know that was the first question that our company had when we looked at 3CX for voice. Management did not want any unencrypted connections outside the company. This forced us to deploy IPSEC VPN's for those users who would be using 3CX remotely with xlite or hardware phones. TCP also allows for better handling of out of order packets and/or jumbo packets.

OCS also provides full encryption of all communications be default (You can turn it off partially). The SIP control connection and RTP payload. This is extremely important if you want to prevent unauthorised access to a VoIP server that is exposed to the public internet. While many people do run 3cx and other SIP based servers over the internet, the risk is that the SIP control connection can be comprimised and very private information can be revealed that could allow a third party to impersonate a user and or steal service.

I think it would be wise for 3CX to have both TCP and secure sip support for both signaling and the secure RTP for the voice/video payload. Polycom and other hardware phones already support secure connections as do many soft phones. I know it would give my company a lot more piece of mind to know that their communications are fully encrypted when out of the office. It would also make my job easier. I would no longer need to work out all of the details/troubleshooting that goes along with IPSec connections.

 

[N_G]

Hi Moon,

Thanks for your feedback. Do you work for Microsoft?

Enforcing TCP is against the RFC: http://tools.ietf.org/html/rfc3261. See section 18: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.

So clearly enforcing TCP is NOT allowed. Moreover, 3CX actually supports TCP. We are fully aware of the advantages of TCP. But the way Microsoft negotiates, its not RFC either and our TCP never 'kicks in'. As a matter of fact our 3CX Tunnel uses TCP, so there is no problem using TCP with 3CX.

In regards to security, there are plenty of ways to implement this well. For example, you could implement an OpenVPN link between sites easily. We are actually planning on making a free install to do this. Though anybody can do it today easily by downloading and installing OpenVPN. Some phones are rumored to ship with an OpenVPN client as well very soon. Yes, IPsec is a pig, but then again this is a microsoft thing. I was forced to study it for my MCSE But there are so many better ways to do security nowadays.

I dont want to sound anti microsoft because we are not. We love windows. And the new windows 2008 is great.

However Microsoft OCS has been designed from the ground up to disrupt the VOIP and SIP standard and lock customers in to Microsoft standards. Witness the proprietary codecs, TCP as mentioned above, and plenty of other stuff. Note also that the Office Communicator 2007 only works with OCS. This is leveraging the Office installed base to try and enforce OCS. This is illegal here in the European Community and legal proceedings are just a matter of time. Office Communicator 2007 MUST and will support interoperability with 'real' SIP servers as well.

That said we are not ruling out OCS in the future, we are keeping a close eye on its development and will re-consider it in the future

 

[moon1234]

I don't work for Microsoft, but I am also an MCSE. (Since 1998). I can see both sides of the coin. Microsoft is trying to leverage their installed base. Their is nothing wrong with that. I have spoken with our local Microsoft Gold parter about their experience with OCS. (They mainly deploy Cisco Call manager). They were actually very upbeat about the product. Not just from the revenue generation side.

They said Microsoft has a much better integration than Cisco when you look at the whole package. They said Voice, Video, Roaming Clients and Mobile Clients (Think Window Mobile) are all housed under a single umbrella and the package works well. I can confirm this. I have the predecessor to OCS 2007, LCS 2005. I have been running it for several years. I can confirm that Voice, Video and Mobile clients works seamlessly. The voice codec does fallback gracefully as network conditions decline.

When speaking with my local vendor they said they have a Beta copy of the next version of OCS that will be released in late fall this year. The vendor said that Microsoft will have some major enhancements to their product that will allow for more traditional telephony features along with voice via the OCS mobile client. The US based cell carriers put up a big stink about Microsoft deploying VoIP via the data channel on the cell network. It completly cuts out the carrier from billing for minutes. In the US many cell data plans are unlimited use. The mobile client already does mobile voice on Windows Mobile, but only via a WiFi connection. This restriction will be gone. Forking works well. I can be logged in on my laptop at home (Without VPN), Desktop at Work and my Cell. When a call comes in all three ring. Presence is updated automatically as I transition from device to device. Presence is then available in Word Documents, Outlook, Sharepoint Sites, Microsoft CRM, etc.

I am not trying to be a Microsoft fan boy. I just think the package works well. It is still missing what I consider core telephony features. Which is why we are using 3CX for that. What I wish 3cx had was support for SRTP and SIPS. It is the one thing that makes me hesitant about deploying more devices outside of the campus.

For integration between LCS and 3CX I am currently using an Audiocodes Gateway. I wish I could go IP direct, but as you stated this still not working well. My vendor said this is supposed to be enchanced in the mediation server in the next rev or two. He stated that MS will have base communication with other SIP servers, but only over TCP. We will just have to wait and see.

 

[jasonshave]

I'm with moon1234 on this one....

...and I don't see how Office ties into the argument. You can install OCS and the Office Communicator client without MS-Office.

If 3CX supports TCP then that argument is moot.

I work for a Microsoft Gold Certified Partner in North American and I can tell you that OCS is our number one application being deployed these days with Exchange UM a close second. Our customers range from enterprise to small businesses and I see 3CX fitting well with the smaller multi site clients. The biggest reason OCS is so attractive is that these clients often have Microsoft entperprise license agreements in which OCS is included at next to no cost at all.

Its a shame 3CX isn't paying more attention to this. There's a lot of finger pointing going on as well and in the end other products like "pbxnsip" integrate well with OCS and even include documents on how to make it happen. I've paid my money to pbxnsip for now even though I like 3CX much more from an admin interface/features perspective. If I were 3CX I'd be working VERY close with Microsoft today and in the future........who knows, maybe Microsoft will bring out their own PBX? 8)

 

[jasonshave]

Many of our clients want a seamless integrated solution for IM, voice, on-premise web conferencing, and voice mail. OCS offers this and more...

From the Office integration (able to see presence such as "on a call" or "in a meeting") to the click to call back and conversation history ability, this product is exactly what many of them are looking for. Being able to IM someone internally and through a federated partner like ourselves or Microsoft is another great feature. Having public IM clients in their buddy lists and being able to communicate securely over almost any platform....what more can I say.

With all this said I still recommend Cisco Call Manager and other products to clients. OCS isn't the end all be all....

Either way I'm excited to see what version 7 offers up....I'm crossing my fingers for OCS integration.

 

[carlos.asj1]

I'm new on the 3CX system but from what I see it's a great product!! Works very well with Exchange Server and all the developers have my congrats!

But I was decided to try 3CX because the OCS integration, and now that I know that is not possible, I'll try another one, like pbxnsip.
Please, make the 3CX compatible with OCS.

 

[FIT4IT]

i would also think about a purchase if OCS integration is available