Subscribe
Lync,Exchange,VoIP,telephony

Archive for the ‘Interoperability’

Polycom® KIRK® permit tu use multi-cell DECT with Microsoft Lync

April 22, 2012 By: Yann Espanet Category: Hardware Device, Interoperability

Polycom® KIRK® offers the first-ever professional DECT multi-cell solution that directly interoperates with Microsoft® LyncTM Server 2010, which will simplify your administration and reduce costs.

With the KIRK Wireless Server 6000 solution and Microsoft Lync, Polycom offers the first-ever professional multi-cell DECT solution directly interoperating with Microsoft Lync Server 2010. By adding KIRK DECT to your UC solution, you will experience all the benefits from vertical mobility, central administration and a high return on investment.

Interoperability with Lync :
http://www.polycom.com/global/documents/products/voice/datasheets/kirk-microsoft-lync-interoperability-datasheet.pdf

How to :
Using a Polycom® KIRK® Wireless Server 6000 Solution in a Microsoft® Lync™ Server 2010 Setup

Office Communicator for various phones : IPhone, Blackberry, Java Phone

November 01, 2009 By: Yann Espanet Category: Interoperability, Office Communication Server

Communicator for Apple IPhone :

iDialog is an OCS 2007 and OCS 2007 R2 compatible client for the Apple iPhone and iPod Touch.

IMG_0026IMG_0024

Participate in IM message and Forward incoming OCS Voice Calls

iDialog supports the following features:

  • Display OCS contact list and presence information
  • Set presence information, including custom note and location data
  • Search corporate Global Address List (GAL)
  • Send and receive Instant Messages (IM)
  • Add multiple participants to an IM conversation
  • Manage and participate in multiple IM conversations simultaneously
  • Control incoming OCS Voice calls (forward/redirect an incoming OCS call to another device, such as an iPhone, voice mailbox, or another phone number)
  • Call a phone number listed on a contact card (This feature is not available on iPod Touch devices)
    Send an email to an address listed on a contact card

http://www.modalitysystems.com/idialog/

Communicator for BlackBerry :

What you can do :

  • Initiate and manage group chat sessions of three or more participants from your smartphone
  • View the presence status of contacts, such as online, busy, do not disturb, be right back, away or appear offline and set your own status to inform others of your availability
  • Enjoy a synchronized contact list, with the same contacts available on your BlackBerry smartphone and your computer
  • Find contacts quickly with the quick find function and picture association
  • Receive alerts when team members become available

Download the BlackBerry Client for use with Microsoft Office Communications Server 2007

http://na.blackberry.com/eng/services/server/exchange/ocs2007.jsp

 

Communicator for Java Phones :

Java Based Phones (Nokia S40/S60 series and Motorola RAZR v3 Devices)

Microsoft makes a version of Office Communicator Mobile R2 available that is optimized for Java. There are different versions available depending on your phone (listed below). OCS 2007 R2 must be running on the backend.

a) Office Communicator Mobile 2007 R2 for Java (Nokia S60 320X240 resolution)

– Supported Phone Models: E51, E66, N95;  Supported Telecom Network: Vodafone and Orange networks in Europe, Airtel and Vodafone networks in India.

b) Office Communicator Mobile 2007 R2 for Java (Nokia S60 240X320 resolution)

– Supported Phone Models: E51, E66, N95;  Supported Telecom Network: Vodafone and Orange networks in Europe, Airtel and Vodafone networks in India.

c) Microsoft Office Communicator Mobile 2007 R2 for Java (Nokia S40)

– Supported Telecom Networks: Vodafone and Orange networks in Europe, Airtel and Vodafone networks in India;   Supported Phone Models: Nokia S40 5th edition phones including: 3120 Classic, 3600 Slide, 5220 XpressMusic , 5310 XpressMusic , 5610 XpressMusic, 6212 Classic, 6300i, 6301, 6500 Classic, 6500 Slide, 6600 Fold, 6600 Slide, 7210 Super Nova, 7310 Super Nova, 7510 Super Nova, 7610 Super Nova, 7900 Prism and 8800 Arte

d) Microsoft Office Communicator Mobile 2007 R2 for Java (Motorola Razr V3 U.S.)

– Supported Telecom Network: AT&T (US); Supported Phone Models: Motorola RAZR V3xx

Remove Plus From Request URI OCS 2007 R2 : bypass RFC 3966 compliance for OCS R2

October 25, 2009 By: Yann Espanet Category: Interoperability, Office Communication Server, SIP trunk

How to make OCS 2007 R2 non-RFC 3966-compliant ?
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. Unfortunately, some IP-PBXs don’t comply with RFC 3966 and do not accept numbers that are prefixed with a plus sign (+).

In OCS 2007 R2 use a new WMI setting, RemovePlusFromRequestURI, which is described in this TechNet article called Enterprise Voice Server-Side Components.
According to the TechNet article, Office Communications Server 2007 R2 introduces two new Windows Management Instrumentation (WMI) settings for Mediation Server. The first new setting specifies how Mediation Server processes E.164 numbers in outbound calls. The second new setting enables Quality of Service (QoS) marking on Mediation Server.

Handling E.164 Numbers in Outbound Calls (OCS 2007 R2)
By default, E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls are prefixed with a plus sign (+). Most Private Branch eXchanges (PBXs) process such numbers without problem. Certain PBXs, however, do not accept numbers that are prefixed with a plus sign.

To ensure interoperability with these PBXs, Mediation Server has a new WMI Boolean setting called RemovePlusFromRequestURI, which has two values: TRUE and FALSE. If your PBX does not accept numbers prefixed with a plus sign, the value for the WMI setting should be set to TRUE, which causes Mediation Server to strip the plus sign from a Request URI for outbound calls. The default is FALSE, which causes Mediation Server to pass the outgoing INVITE’s Request URI, To URI, and From URI unchanged.

The TechNet article also discusses compatibility with PBXs that do not support the plus (+) sign.

By default, E.164 numbers in the Request URI of outgoing calls from Office Communications Server 2007 R2 are prefixed with a plus sign. Most PBXs process such numbers without problem. Some PBXs, however, do not accept numbers that are prefixed with a plus sign and do not route those calls correctly.

Additionally, the From headers of inbound calls from some PBXs does not conform to RFC 3966 because they are not prefixed with a plus sign. Microsoft Office Communicator cannot resolve these numbers to the correct user.

To assure interoperability with these PBXs, Office Communications Server 2007 R2 has a new Mediation Server setting for WMI called RemovePlusFromRequestURI. This setting can be set to YES or NO. The default value is NO.

– If a PBX downstream from the Office Communications Server 2007 R2 Mediation server does not accept numbers prefixed with a plus sign, set the value of RemovePlusFromRequestURI to YES. This causes Mediation Server to remove the plus signs from the Request URIs of outgoing calls. It also causes the plus signs to be removed from the To and From URIs.
– If the downstream PBX accepts numbers prefixed with plus signs, leave the value of RemovePlusFromRequestURI set to its default value of NO. This causes Office Communications Server 2007 Mediation Server to pass Request URIs, To URIs, and From URIs unchanged (that is, with plus signs).

Extract from : http://tmcnet.com

Using Asterisk to pass and receive SIP calls from Microsoft OCS to a SIP Trunk in UDP

August 04, 2009 By: Yann Espanet Category: Hardware Device, Interoperability, SIP trunk

Enabling Any SIP Phone & Any SIP Trunking Service Provider with OCS 2007 R2 !

Goals of the demo :

Use asterisk like a UPD/TCP translator between OCS and a SIP trunking services in UDP mode.

  • make calls from Microsoft Office Communicator to the sip trunk
  • dial froma external mobile or a PSTN phonetrough the sip trunk and answer the call on eithera hard or soft phone or Office Communicator.
  • control forwarding and simultaneous ringing options from the Communicator

I use Asterisk 1.6 which support TCP and UDP installed on CentOS 5 – Kernel 2.6.18

Installation steps :

  1. Add a mediation server to the OCS infrastructure
  2. Add an asterisk server
  3. Configure Mediation server to use the asterisk box
  4. Resolve NAT problem (if needed)
  5. Create two SIP trunks :
    1. Asterisk to OCS
    2. Asterisk to SIP Trunk service
  6. Define the context used by this trunks
  7. Configure follow me
  8. Test the infrastructure

Basic schema :

OCS R2 —- Mediation —- Asterisk —— Firewall — SIPTrunk
MTLS —- TCP —- UDP —- NAT —– UDP

I use Hyper-V for the two OCS servers and VMware for the Asterisk server.

Step-by-steps

Step 1 : Add a mediation server to your infrastructure

  1. Install a mediation server
  2. Configure certificate
  3. Add the OCS reskit tools (useful for troubleshooting)
  4. Create a dial plan
  5. Create a location profile with two normalization rules.
The first will be use for internal numbering and the second is a generic rule that redirect all call that do not correspond to a valid extension number in OCS to the default gateway.
Internal : OCS user have an three digit extension beginning by 2
Phone pattern : ^2(\d{2})$
Translation pattern : +2$1
Generic rule : All number are concerned (be careful to put this rule in second position in your location profile)
Phone pattern : ^(.*)$
Translation pattern : $1
Assign your location profile to front-end server (properties of the pool / properties of front-end / Voice Tab)
NB : Test your dial plan using the Enterprise Voice route helper

The first will be use for internal numbering and the second is a generic rule that redirect all call that do not correspond to a valid extension number in OCS to the default gateway.

  • Internal : OCS user have an three digit extension beginning by 2

Phone pattern : ^2(\d{2})$

Translation pattern : +2$1

  • Generic rule : All number are concerned (be careful to put this rule in second position in your location profile)

Phone pattern : ^(.*)$

Translation pattern : $1

Assign the location profile to the front-end server (properties of the pool / properties of front-end / Voice Tab)
NB : Test your dial plan using the Enterprise Voice route helper

Step 2 : Add an asterisk server

  1. Download trixbox 2.2 Virtual Appliance from VMware website http://www.vmware.com/appliances/directory/939
  2. Configure basic settings (Ip address, ..)
  3. Add this line in the begining of sip.conf

tcpenable = yes
bindport = 5060

  1. Access the web Trixbox interface (use Mozilla) In system menu / Network / Configure IP, Subnet, DNS and a valid hostname on internet : Ex : sip.mydomain.com

Step 3 : Configure Mediation server to use the asterisk box

  1. Open the properties of your mediation server verify that :
  2. in General tab : the gateway listening port is 5060
  3. In next hop connections tab : put the IP address of your asterisk server in PSTN gateway next hop with 5060 for the port number

Step 4 : Resolve NAT problems (if needed)

  1. In Asterisk, Go to PBX / Config File Editor / and edit SIP_NAT.conf

nat=yes

externip=Valid_FQDN

localnet=Your_Localnet/Your_Subnet

  1. Open in your firewall port
    • 5060 in UDP and TCP for SIP
    • RTP: 10000 to 20000 UDP
  2. Verify that you can see you valid public IP in the Trixbox system status

Step 5 : Create two SIP trunk in Trixbox : asterisk to OCS and Asterisk to SIP Trunk service

  • Asterisk to OCS

Trunk Name : ocs

PEER Details :

host=ip-mediation-server

type=peer

qualify=yes

transport=tcp

insecure=very

port=5060

canreinvite=yes

fromdomain=yourdomain

context=from-ocs

Incoming Settings :

User context : (I put a OCS username here)

User details :

host=ip-mediation-server

type=peer

transport=tcp

insecure=very

port=5060

context=from-ocs

register string :

(leave blank)

  • Asterisk to SIP Trunk service

Trunk Name : siptrunk

PEER Details :

type=friend

disallow=all

allow=ilbc&speex&gsm&alaw&ulaw

username=username

secret=password

host=yoursipregistrar

canreinvite=no

context=from-siptrunk

Incoming Settings :

Clear all

register string :

username:password@yoursipregistrar (/yournumber if needded)

Step 6 : configure context

Edit Extension_Custom.conf and add a the end of the file :

[from-ocs]

exten => _X.,1,Answer

exten => _X.,2,Dial(SIP/${EXTEN}@siptrunk,,tr)

#include extensions-away-status.conf

[from-siptrunk]

exten => _X.,1,Set(numDialled=+${EXTEN:Number_of_X_to_ignore})

exten => _X.,2,Set(__FROM_DID=${EXTEN})

exten => _X.,3,Answer

exten => _X.,4,Dial(SIP/${numDialled}@ocs,,tr)

exten => _X.,4,Dial(SIP/${numDialled}@ocs)

Step 7 : Configure follow-me in Asterisk

Assign line number from your sip trunk to Asterisk extension and redirect to phone extension in OCS by using a # after the number.
DID number from your SIP trunk provider —> Extension in Asterisk —> Follow-me to OCS extention (use # after the number to precise that it’s external to asterisk)

Step 8 : Test the infrastructure

  1. Troubleshooting tools that you can use in Asterisk :
    1. Log as root with a terminal tools (putty) / Type asterisk –r / Type sip set debug on
    2. Assign a line prefix to test the trunk from a softphone directly connected to Asterisk
      Ex : Create a outbound route with “9|.” to test the trunk by dialing 9 before the number
  2. Troubleshooting tools that you can use in OCS :
    1. Eventviewer
    2. Use the Debug tools (right click your mediation server)
    3. MS Netmon
    4. OCS Route helper to validate your dial plan.

Have fun with that and leave me a message if encounter some problems!

It’s probably possible to do the same withother IP/PBX like : Freeswitch, OpenSer, SipxECS, …

Date : 04/08:2009 – Author : Yann Espanet – mail : yann@unifiedcommunications.eu

Why Microsoft use TCP instead of UDP for SIP ?

July 21, 2009 By: Yann Espanet Category: Interoperability

Is better to use TCP rather than UDP for SIP message fragmentation concerns ?

First concerns : maximum size of a UDP datagram

The maximum message size for a UDP datagram socket is limited by the maximum size of an IP datagram and the size of the UDP datagram socket buffer.
The maximum size of an IP datagram limits the maximum message size of a UDP message to 65507 bytes. Therefore, using the maximum socket buffer size will allow multiple maximum-sized messages to be placed on the send queue. The default inbound and outbound message size limit for a UDP datagram socket is 65535 bytes.

The maximum message size for a UDP broadcast is limited by the MTU size of the underlying link, which is 1500 on Ehternet.

Here’s the MTU for different media :

Network MTU

Token Ring 16 Mb/s 17 914

FDDI 4 352

Ethernet 1 500

IEEE 802.3/802.2 1 492

PPPoE 1 480

X.25 576

UDP has no fragmentation mechanism like TCP or IP, but it used the fragmentation of IP layer.

Transmission Control Protocol (TCP) is an example of a protocol that will adjust its segment size to be smaller than the MTU.
User Datagram Protocol (UDP) disregard MTU size thereby forcing IP to fragment oversized datagrams.

Conclusion :

TCP provide transport-layer fragmentation. If a SIP message is larger than the MTU size, it is fragmented at the transport layer. When UDP is used, fragmentation occurs at the IP layer. IP fragmentation increases the likelihood of having packet losses and makes NAT and firewall traversal difficult, if not impossible. This feature will become important if the size of SIP messages grows dramatically.

Second concerns : Multiple-Stage Fragmentation

While the fragments above are in transit, they may need to pass over a hop between two routers where the physical network’s MTU is only 1,300 bytes. In this case, each of the fragments will again need to be fragmented. The 3,300 byte fragments will end up in three pieces each (two of about 1,300 bytes and one of around 700 bytes) and the final 2,100-byte fragment will become a 1300-byte and 800-byte fragment. So instead of having four fragments, we will end up with eleven.

IPfragmentation

This example shows illustrates a two-step fragmentation of a large IP datagram. The boxes represent datagrams or datagram fragments and are shown to scale. The original datagram is 12,000 bytes in size, represented by the large gray box. To transmit this data over the first local link, Device A splits it into four fragments, shown at left in four primary colors. The first router must fragment each of these into smaller fragments to send them over the 1,300-byte MTU link, as shown on the bottom. Note that the second router does not reassemble the 1,300-byte fragments, even though its link to Device B has an MTU of 3,300 bytes.

What about the impact on SIP performance ? A CPU problem, not a network problem ..

Today’s SIP application is mostly operating over the unreliable transport protocol UDP. In lossy environment such as wireless networks and congested Internet networks, SIP messages can be lost or delivered out of sequence. The SIP application then has to retransmit the lost messages and re-order the received packets. SIP has a builtin process for dealing with the unreliable nature of UDP, however to parse the SIP data a transition from kernel to usermode is required. This additional processing overhead can degrade the performance of the SIP application.

Conclusion :
It’s not a network problem, but a CPU problem !

Take a look at this study :
http://www.research.ibm.com/people/n/nahum/papers/sigmetrics07-sip-perf.pdf

Security concerns ?

  • UDP packets are not interrogated in the same manner as TCP packets making it an easy way to exploit SIP problems.
  • UDP posses a problem for NAT traversal, QOS, and fragmentation.
  • Authentication – By using TCP you can leverage TLS and SRTP to make it extremely difficult to ease drop on conversations.

What about SCTP to transfer SIP messages ?

Ref : RFC 4168
http://www.rfc-editor.org/rfc/rfc4168.txt

Therefore to solve this problem, the researchers are looking for a more appropriate transport layer for SIP. SCTP, a transport protocol providing acknowledged, error-free, non-duplicated transfer of messages, has been proposed to be an alternative to UDP and TCP. The multi-streaming and multi-homing features of SCTP are especially attractive for applications that have stringent performance and high reliability requirements and an example is the SIP proxy server.

Ref :
http://www.bth.se/fou/cuppsats.nsf/all/7d8446ad03071d5ac12575890073deec/$file/Thesis%20Report%20Final.pdf

But additional testing need to be done, and Microsoft doesn’t support SCTP for the moment !

Another article can be found there :

Increased SIP Performance with Stream Control Transmission Protocol
http://blog.tmcnet.com/cross-talk/2008/07/increased-sip-performance-with-stream-control-transmission-protocol.html

SCTP and its applications
http://www.apng.org/9thcamp/Slide/Satit.pdf

Is Microsoft does not support UDP for SIP implementation at all ?

Right in OCS but not in his small business product !, Microsoft SIP Solution for Small Business support UDP !!

http://www.microsoft.com.nsatc.net/responsepoint/resources-whitepapers-sbsintegration.aspx

“Microsoft Response Point is complete phone system software designed specifically for small businesses with 1-50 employees. In the past, deploying an advanced phone system to a small business was considered impractical.”

“Network Protocols
Response Point transfers data and communicates using standard protocols. Generally, there should not be any network configuration changes needed to support these protocols. All hardware and software connected to your network—the router, SBS, and other computers— should work automatically with the following protocols:

Session Initiation Protocol (SIP over UDP) to establish and coordinate phone calls between devices.

  • Real-time Transport Protocol (RTP) to transmit audio over the LAN in the G.711 μLaw and G.723 encoding formats.
  • Secure Hypertext Transfer Protocol (HTTPS) and Extensible Markup Language (XML) to communicate configuration settings between the Administrator program and base unit, or the Assistant program and base unit.
  • Dynamic Host Configuration Protocol (DHCP) to acquire IP addresses; to discover the location of the base unit; and to discover phones and phone line adapters that have not been provisioned yet.
  • Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML) to provision phones and phone line adapters.”

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 …

Vendor

UDP TCP TLS Reference
Microsoft N Y Y ref
Microsoft Respond Point Y Y Y Ref
Cisco Y Y Y Ref
IBM N 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

clip-image002-thumb.gif

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.

image6 

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 : http://technet.microsoft.com/nl-nl/bb735838(en-us).aspx#direct

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 :

http://blogs.technet.com/ucspotting/archive/2009/02/28/removeplusfromrequesturi-or-how-to-make-ocs-non-rfc-3966-compliant.aspx

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.
http://www.telecomengine.com/NewsGlobe/article.asp?HH_ID=AR_5008

 

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.

4.1.4.3 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 : http://technet.microsoft.com/en-us/library/dd441216(office.13).aspx

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

http://www.evangelyze.net/brochures/SmartSIP%20Brochure.pdf

 

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 !

Interoperability between OCS 2007 and CISCO Unified Communication Manager

December 27, 2008 By: Yann Espanet Category: Interoperability, Whitepapers

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/716742.pdf

This document describes the simultaneous ring feature interoperability and documents the steps and configurations necessary for Cisco Unified Communications Manager (Cisco UCM) Release 7.0(1) to interoperate with Microsoft Office Communications Server (OCS) 2007 Enterprise Edition. It aims to provide a good understanding of what works and what does not work in terms of the feature interaction between a Cisco UCM device and Microsoft Office Communicator. It also provides guidance to deployment participants regarding the limitations, expected behaviors, and known issues. Please note that this document does not address performance and scalability, which are part of a broader criteria for a deployment-ready solution.