What’s new on interoperability between OCS R2 and SIP/PSTN Gateways, IP-PBXs and SIP Trunking Services.

March 22, 2009 By: Yann Espanet Category: Interoperability, Office Communication Server

What is the interoperability problem between Microsoft OCS and IP/PBX or why do I need a mediation server and/or a gateway if I want enterprise telephony ?

Because of transport protocol and Audio codec … I will try to give my answers but if you’re not agree don’t hesitate to comment this post.

Let’s examine the problem statement :

First interoperability problem, the Transport protocol used for SIP.

Microsoft tries to push SIP implementations towards more reliability and security by using TCP for SIP transport protocol and SIP over TLS for security, but a few SIP vendors are capable to inter operate with these specifications.

Microsoft argues that he respects the original SIP specification :

  • IETF RFC 2543 which was ratified in March 1999 : This RFC doesn’t specify to use TCP for transport, but only that TCP and UDP are supported for SIP operation :

Extract form RFC 2543 :
10 Behaviors of SIP Clients and Servers
10.1 General Remarks
SIP is defined so it can use either UDP (unicast or multicast) or TCP as a transport protocol; it provides its own reliability mechanism.

  • IETF RFC 3261 was ratified in June 2002 and specify clearly the use of TCP for SIP, but the system SHOULD retry the request, using UDP for backwards compatibility with RFC 2543 compliant implementations :

“All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them.”
“If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification. “

While many vendors had made initial investments in next-generation communications using SIP and RTP, the technology implementations were often several generations behind those being utilized in Office Communications Server 2007. One example of this is that few of these elements supported TCP as a SIP transport protocol even though this was part of the original SIP specification, IETF RFC 2543, which was ratified in March 1999.

Even fewer vendors supports the use of Transport Layer Security (TLS) to encrypt SIP traffic. Therefore, a consequence of Microsoft’s progressive standards support and innovation is that Microsoft Clients and Servers do not inter operate with some SIP-based telephony elements.

Here’s the problem : OCS doesn’t support UDP for backyard compatibility according to RFC 2543 causing interoperability’s problems with not up-to-date SIP gateways !!

  • What is the advantage of using TCP for SIP communications ?

The response fit in two words : Encryption, fragmentation,

Encryption : UDP is not encrypted, so you cannot ensure end to end security of SIP messages. This is why OCS uses TLS over TCP as the default SIP transport within the OCS network.

Fragmentation : The maximum size of the UDP datagram is limited to 1500 bytes, so a SIP message larger than that will be broken into two or more packets. OCS SIP messages tend to contain various information like XML bodies, and GRUUs, ICE candidate attributes, so they will normally span multiple packets, with a probability of losing one of them, and need a retransmission in UDP transport mode.

“Usually, the size of MESSAGE requests outside of a media session MUST NOT exceed 1300 bytes unless the UAC has positive knowledge that the message will not traverse a congestion-unsafe link at any hop” 
Ref: RFC: 3428

It recommends the use of TCP for transport protocol over this size of 1300 bytes, that what OCS do ! 

  • Is UDP, the preferred protocol for SIP transport ? Not really …


UDP TCP TLS Reference
Microsoft N Y Y ref
Microsoft Respond Point Y Y Y Ref
Cisco Y Y Y Ref
Nortel Y Y Y Ref
Avaya Y Y Y Ref
Alcatel-Lucent Y Y N Ref
Siemens Y Y Y Ref
AudioCodes Y Y Y Ref
Nextpoint Y Y Y Ref
Acme Packet Y Y Y Ref
Covergence Y Y Y Ref
Asterisk* Y N N Ref

* experimental TCP and TLS support for SIP in Asterisk 1.6.2

Consequently, It’s not really the big problem for interoperability if almost all vendors support TCP and TLS, isn’t it?

Second problem : Proprietary Real Time Audio and Real Time Video codecs from Microsoft

To enable transmission of voice traffic over an IP network, it is essential to convert an analogue voice wave to a digitized voice stream. Audio translation is provided by various types of codecs and must define 2 key aspects, namely coding method and compression mechanism.

G.7xx, including G.711, G.721, G.722, G.726, G.727, G.728, G.729, is a suite of ITU-T standards for audio compression and de-commpression. G.711 (wave form) & G.729 (source form) are the two most-commonly CODECs used in VoIP systems. There are many other types of CODECs used in special applications such as Polycom’s SIREN and RT-A-Real-Time Audio used in Microsoft’s OCS-Office Communications Server.

Name standard description bit rate (kb/s) sampling rate (kHz)
G.711 ITU-T Pulse code modulation (PCM).
G.711 with mu-law used in North America and Japan, while G.711 with A-law used in the rest of the world.
64 8
G.729 ITU-T Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear-prediction (CS-ACELP) 8 8

The PSTN network digitizes analogue packets into 64kbps streams using the G.711 codec which is then transported over dedicated Time Division Multiplexing (TDM) voice channels (64kbps bandwidth). For optimal use of limited network resources, a WAN environment typically deploys the G.729 codec which uses compression to bring the voice stream down to 8kbps.

G.711 operates with a constant bit rate and works best in networks with guaranteed bandwidth since it is prone to packet loss in congested networks. The H.323 standard defines at least the audio service as specified in ITU-T G.711 for audio codec at 64kbps*.

Nevertheless, audio packets can traverse multiple network segments with varying degrees of bandwidth and reliability, some of which are completely outside of your own control. To this end, Microsoft designed RTAudio which is an adaptive wide-band, variable bit rate speech codec less susceptible to packet loss.

Essentially, RTAudio dynamically switches between the G.729 and G.711 codecs to keep an audio conversation alive rather than dropping it altogether if possible. The Quality of Experience (QoE) of the audio ouput can fluctuate from high fidelity (16kHz wide band) to as low as 24kbps, and is dependent on network conditions. This proprietary codec is an integral part of the Unified Communications family of product, and should not be confused with Real Time Protocol (RTP). The latter is responsible to move voice traffic using standardized packet formats in real-time over UDP on the network. Together with RTP Control Protocol (RTCP), the Quality of Service (QoS) provided by RTP can be adjusted by applications using this information e.g. switch over to low-compression codec.

The audio codec used in VoIP communications between a PBX and Mediation server can only be G.711 (either aLaw or uLaw as defined by the phone system) and the internal OCS audio and video communications can only use Microsoft’s proprietary Real Time Audio and Real Time Video codecs.

So, end-Point need to understand the codec used for audio, and the problem is that this codec is proprietary to Microsoft , and the only way for other vendors’ phones to talk to Microsoft endpoints is via Microsoft’s Mediation Server, which codes Microsoft RTP flows from G.711 to RTAudio (8kHz) and SIREN.

Ref : RTAudio Protocol document

Microsoft RTVideo and Microsoft RTAudio codec porting kits

RCP is a protocol that is defined by the IETF in RFC 1889

Advantages of using Microsoft Codec :

  • More tolerant to Packet loss : traditional codecs are sensitive to packet loss:
    • “Even a 1% loss can significantly degrade the user experience with G.711, which is considered the standard for toll quality”
    • “The default G.729 codec requires packet loss far less than 1% to avoid audible errors,”

In the opposite, Microsoft said that his audio healing capabilities matching or exceeding PSTN fidelity in a 10% packet loss situation.

  • Less Bandwidth

Bit rate comparison with traditional codecs


Microsoft RTaudio use less bandwidth for the same or better audio quality.

Another improvement of the use of the bandwidth is two another functionality : Voice Activity Detection/Silence Suppression (VAD/SS) detects the presence or absence of speech from the user’s microphone, and stops packets from being sent over the network if the user is not talking and Noise Suppression (NS) isolates and removes non-speech signals from the signal captured by the microphone help to preserve bandwidth for useful data.

Ok, here’s a clear problem that affects the use of a mediation server to translate the codec !

But you can use OCS phones to connect directly into OCS :

Nortel, Polycom and Tandberg have paid for the license and their endpoints call into OCS without Mediation Server.

See the RTaudio and RTvideo Intellectual property page:

Microsoft RTVideo and Microsoft RTAudio codec porting kits
RTVideo and RTAudio codecs are real-time Microsoft video and audio codecs developed for the Windows Live Messenger, Microsoft Office Communications Server 2007, Microsoft Office Communicator 2007 and Microsoft Office Live Meeting 2007 platforms. The RTAudio codec is designed for both high quality wideband and narrowband voice over IP (VoIP) applications, including applications such as, games, audio conferencing, and wireless applications over IP. The RTVideo codec provides high quality, efficient, robust real-time video communication over IP networks.

and download : Overview of the Microsoft RTAudio Speech codec

Actually, Intel, Texas Instruments, AudioCodes, Dialogic, LG Nortel and Polycom have licensed Microsoft’s RT Audio Codec for their gateways product of future OCS enable phone.

Do I need only a mediation server or do you need also a gateway ?

It depend on your PBX vendor, but in almost all case you need a mediation server and a media gateway.

To connect your Office Communications Server 2007 environment to a PBX or PSTN and enable enterprise voice, you must deploy a media gateway, also referred to as a SIP/PSTN or IP/PSTN gateway. The media gateway must be paired with a Mediation server to connect to your Office Communications Server 2007 environment, as shown in the following figure.


The Mediation server makes it possible to connect media gateways that support standard, even unsecured SIP implementations with Office Communications Server 2007, as OCS 2007 allows only authenticated and encrypted communication. Another task of the Mediation server is to handle codec translations between the standard codecs (G.711, G.723, and so on) and the Microsoft real-time audio codec.

There’s two type of gateway :

  • Basic Media Gateway
    • Standalone appliance image14
    • upports TDM features
    • SIP over TCP
    • RFC 3261 compliant SIP
    • G.711
    • Works with Mediation Server

  • Hybrid Media Gateway image14
    • Media Gateway appliance
    • Collocated with Mediation Server


For the moment, here’s the different combination that you can use :

Gateway Vendor Tested Product Qualification Level Gateway Configuration Other Supported Products OCS R2 OCS
Aculab ApplianX Gateway for Office Communications Server 2007 Direct SIP via Gateway Basic Hybrid    
AudioCodes Mediant 1000 Direct SIP via Gateway Basic Gateway MediaPack 11x  
Mediant 1000 Direct SIP via Gateway Basic Gateway MediaPack 11x  
Mediant 2000 Direct SIP Connectivity via Gateway Basic Gateway MediaPack 11x, Mediant  
Mediant 2000 Direct SIP Connectivity via Gateway Basic Gateway MediaPack 11x, Mediant  
Mediant 2000 Hybrid Direct SIP Connectivity via Gateway Basic Hybrid MediaPack 11x, Mediant  
Cisco 2851 Integrated Services Router Direct SIP via Gateway** Basic Gateway 2800 Series  
3845 Integrated Services Router Direct SIP Connectivity via Gateway** Basic Gateway 3800 Series  
Dialogic 2000 Direct SIP viaGateway Basic Gateway DMG1000 and DMG2000 Series  
2000 Direct SIP viaGateway Basic Gateway DMG1000 and DMG2000 Series  
4000 Direct SIP Connectivity via Gateway Basic Hybrid DMG4000 Series  
Ferrari electronic AG OfficeMaster Gate Direct SIP via Gateway Basic Gateway    
Mitel 3300 Direct SIP via IP-PBX IP-PBX    
NEC SV70 OCS-GW-A Direct SIP via Gateway Basic Gateway    
NET VX1200 Direct SIP via Gateway Basic Gateway VX Series  
VX1200 Direct SIP via Gateway Basic Gateway VX Series  
Nortel Secure Router 4134 Direct SIP via Gateway Basic Hybrid    
CS 1000 Direct SIP via IP-PBX IP-PBX    
Nuera Communications GX-1K Direct SIP via Gateway Basic Gateway    
GX-2K Direct SIP Connectivity via Gateway Basic Gateway    
Quintum Tenor DX Direct SIP via Gateway Basic Gateway Tenor AS, AF, AX, BX, DX and CMS Series  
Tenor DX Direct SIP via Gateway Basic Gateway Tenor AS, AF, AX, BX, DX and CMS Series  
Tenor Hybrid Gateway 60 Direct SIP Connectivity via Gateway Basic Hybrid    
Seltatel SAMoffice 4 Direct SIP IP-PBX    
Tango Networks Abrazo (qualified with Audiocodes Mediant 2000 5.20A.043) Direct SIP via Gateway Basic Gateway    
VegaStream Vega400 Direct SIP via Gateway Basic Gateway Vega50 Europa Vega 5000  

Source :

NB: Another problem even if you use a mediation server can be interoperability issues with non E.164-compliant PBXs.

Office Communications Server 2007 Mediation Server uses a plus sign (+) to prefix E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls. However, certain private branch exchanges (PBXs) do not comply with RFC 3966 and do not accept numbers that are prefixed with a plus sign (+).

But you can make OCS and OCS R2 non-RFC 3966-compliant, but using the WMI setting named RemovePlusFromRequestURI.

Follow this article to obtain code to enable this setting :

Microsoft is working to provide support to connect the Mediation server directly to the IP PBX without the intermediary of a media gateway, this solution is called : Direct SIP connectivity !

What is Direct SIP Connectivity ?

Direc SIP is the documented and supported way in which Microsoft Office Communications Server exchanges voice calls with third-party on-premise devices such as SIP/PSTN gateways and IP-PBX. In Direct SIP, an Office Communications Server’s Mediation Server is directly connected to a SIP/PSTN gateway or an IP-PBX. Microsoft provides the Unified Communications Open Interoperability Program (OIP) for the qualification of third-party solutions for interoperability with Microsoft Office Communications Server. Under the OIP, Direct SIP is based upon common industry standards (SIP over TCP, RTP, G.711). Direct SIP with a SIP/PSTN gateway enables Office Communications Server to exchange calls directly with the PSTN, as well as with virtually any TDM PBX, and (via back to back SIP/PSTN gateways) with virtually any IP-PBX.

The only choices can be :

  • Cisco Call Manager 5.1 and Cisco Unified Communications Manager 6.0, but with loss of functionality
  • Nortel PBX systems

Well, that’s pretty lame, considering there are dozens of decent SIP trunking service providers and probably hundreds across the entire world.

A new magor player is Verizon business who recently offers SIP trunking (as well as hosted IP Centrex) in 12 countries for OCS R2.


The SIP Connect initiative : IP PBX and Service Provider Interoperability

The problem is that it’s hard to provide feature-rich communication applications across vendors and providers because in the RFC there is :

  • Too many MAYs
  • Too many SHOULDs

The SIP Forum began working on SIPconnect subsequent to the initial release of the SIPconnect Interface Specification in February, 2005 based on a proposal submitted by members of the SIPconnect initiative. The SIP Forum created the “IP PBX and Service Provider Interoperability Task Group” on July 15, 2005 to continue this work and in september, 2007, the SIP Forum launched the SIPconnect Compliance Program.

The SIP Forum reached an important milestone in January, 2008 as it formally ratifies version 1.0 of the SIPconnect Technical Recommendation with the unanimous approval of the SIP Forum Board of Directors and announces the formation of the SIPconnect v.1.1 Task Group.

To download the ratified SIPconnect Technical Recommendation Version 1.0, please click here.

This first SIPconnect document was ratified by : Cisco, Siemens, Nortel, Avaya, Mittel, … but not by Microsoft.

This document try to eliminate the too many MAYs and SHOULDS and to be agree on what MUST exist, if we look at the latest SIPconnect Technical Recommendation Version 4.0 : it’s not fully compatible with Microsoft SIP implementation: The main divergence are on : the use of TCP, TLS, noise supression, …

Download the SIPconnect 1.1 draft V.04

Even if Microsoft hadn’t ratified the SIPconnect document, they work in the task force to try to give an orientation of this specification towards their products.

You can take a look at the depository of SIPconnect 1.1 Scoping Documents, which currently includes submissions from Avaya, Broadsoft, CableLabs, Cbeyond, MetaSwitch, Microsoft and Siemens,

Extract from :

Microsoft’s Proposal to the SIP Forum For SIP Trunking Interoperability – SIPConnect v2.0

4.1.1 SIP over TCP

SIP, as defined in RFC 3261 is the core control interface between Enterprise Proxy and the Service Provider Proxy. According to RFC 3261 a SIP element MUST support UDP and TCP. However the support of TCP has been made mandatory to accommodate messages larger than 1300 bytes. Since more sophisticated SIP deployments nearly always breach this limit, it is proposed that the Enterprise Proxy and Service Provider Proxy:

  • MUST support TCP
  • MAY support UDP
  • MAY support TLS

Future versions of this document will be likely to make the support of TLS mandatory in order to provide security for SIP messages. Vendors are strongly advised to consider the requirements for TLS support in future versions of their products. Audio codecs

The Service Provider Proxy and Enterprise Proxy MUST support the following codecs:

  • G.711 Glaw
  • G.711 Ulaw

Both the Service Provider Proxy and the Enterprise Proxy MAY support additional codecs.

But what about new IP trunking support in OCS R2 without the need of an IP/PBX ?

Office Communications Server 2007 R2 simplifies and reduces the cost of deploying Enterprise Voice by enabling an enterprise to connect its voice network to a service provider offering PSTN origination and termination. This capability, a variety of what is known in the telecommunications industry as SIP trunking, means that enterprises do not need to deploy IP-PSTN gateways, with Mediation Servers, in order to enable PSTN connectivity.

The Office Communications Server 2007 R2 SIP trunking capability enables the following scenarios:

  • An enterprise user inside or outside the corporate firewall can make a local or long-distance call specified by an E.164-compliant number that is terminated on the PSTN as a service of the corresponding service provider.
  • Any PSTN subscriber can contact an enterprise user inside or outside the corporate firewall by dialing a Direct Inward Dialing (DID) number associated with that enterprise user.

Source :

However at this time Microsoft only supports direct SIP trunking with two providers, namely Global Crossing and Sprint, but another player will come in the field : Verizon Business recently announce that he combines SIP trunking with Microsoft OCS R2.

Is there alternate solutions ?

Evangelyze Communications has some products that enhance OCS 2007 R2 functionality

Evangelyze Communications (EC) SmartSIP solution extends the already powerful telephony capabilities of the Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 platforms by enabling SIP connectivity with virtually any internet telephony service provider (ITSP) or SIP phone.

  • Extends OCS SIP trunk support to virtually any ITSP
  • Multi-SIP trunk support per OCS Mediation Server
  • Improvements to OCS 2007 R2 platform:
    • ENUM support
    • NAT Traversal
    • AD phone number matching for extension/DID
  • Support for generic SIP PBXs and endpoints/devices
  • Virtual gateway service


Last question, will Microsoft OCS 2010 Finally Eliminate the PBX ?

Perhaps, many IP-PBX vendors have fear that one day Microsoft will offer a full-fledged software-based IP-PBX replacement.

Microsoft Business Division President Stephen Elop talks about the debut of Microsoft’s Office Communications Server 2007 Release 2 (R2) and says:

“Office Communications Server 2007 R2 allows customers to take the next step toward replacing their PBX with Microsoft’s unified communications software and managing voice in the same way as other applications such as e-mail and instant messaging.”

So, for the moment, the goals are to “inter operates with legacy PBX and IP PBX investments, allowing customers to transition to the new platform.
Without undergoing an expensive rip-and-replace upgrade of their network.” but in the future Microsoft could offer a full-fledged software-based IP-PBX replacement !

0 Comments to “What’s new on interoperability between OCS R2 and SIP/PSTN Gateways, IP-PBXs and SIP Trunking Services.”

  1. Hello Yann,

    thank you a lot for this article. Detailed explanations liked yours can help a lot, when you need good arguments versus the “everytime” interop or propriority prejudices against OCS R1/R2. I like to add a good example which proves that interop is not impossible or too difficult in case of OCS:
    Please take a look at what snom (the open standard sip phone vendor) has been able to do to its product range with a just firmware upgrade. Today they are offering a complete set of low entry, up to highend phones that can be used nativly with OCS R1/R2. Latest newcomer the snom MeetingPoint is the first & only standalone conference room solution for OCS at the moment. Even if none of the devices is certified, they offer a too interesting and attractive price and feature set, to ignore them. You can find more information here at

    If you think RTA Codec is a must have, please look at the suprising results that Miercom had, during testing snom’s OCS beta firmware:

    At 5.15. the RTM Release (8.2.5) of the FW was published, which offers a lot improvements and can be considered as a virtually ready for action 🙂

    btw: atm there is no program (like the OIP) where you can try to certifiy a phone endpoint for OCS. Even the devices that run Communicator on a Windows CE 5 (Tanjay), like the Polycom or LG-Nortel are not certified for OCS! They are “Optimized for Communicator” like the OC-Headset from Plantronics, GN-Jabra, etc.

    Regards, Jan

  2. anonymous says:

    The article states that UDP has a maximum limitation of 1500 bytes. That is not true. UDP has a length field of 16 bits so it is limited to 2^16
    What you are referring to is the Ethernet MTU size.

  3. Jenny Haynes says:

    Fantastic site, I really like your writing style. Very distinctive and to the point. On a lot of blogs people just drone on and on, but not you – very nice. Keep up the great work! I find Voice over IP very interesting. I have learned a lot in implementing a small VoIP network at home, and am thinking of starting VoIP business in my area. There are a number of small businesses in my region that would benefit from it greatly.