Over the last few weeks I have been doing a bit of research into Avaya and OCS R2 interoperability. When you refer to the OCS Open Interoperability web page you will find Avaya under the supported IP-PBX section. This means Microsoft has tested the interoperability internally and this is not OIP Certified as with other gateways etc. This means Microsoft does support the configuration but the other vendor may not. In saying that Avaya has released some documentation on this interoperability but it has been a while since it was updated.
OCS Enterprise Voice - Avaya interoperability - Direct SIP
Firstly, documentation on this interoperability is hard to find. Avaya have released this document on call routing between the two systems. It is based around using the Avaya SIP Enablement Server version 4.x and OCS R1. This document is about a year and half old which means things have changed since its release but I was unable to find any updated documentation publicly available. One thing about this document is it makes references to Remote Call Control. Its is not applicable to this configuration and is somewhat distracting for it to be in this document.
Avaya did document issues which are listed below:
“On a call between an Avaya phone and an EV client, the EV client is not able to place the call on hold. The microphone and speakers on the EV client are muted, but the call is not actually placed on hold. In contrast, on a call between two EV clients, both EV clients are able to place the call on hold.”
“On a call between an Avaya phone and an EV client, attempts by the EV client to
conference in another Avaya phone or EV client fail” and “On a call between two EV clients, attempts by either EV client to conference in an Avaya phone fail.”
Microsoft have also listed known issues for SES 4.x:
Configuration requires setting "Alternate Route Timer(sec)" value from default of 10 sec to 30 sec. The configuration should show "Alternate Route Timer(sec): 30" in the corresponding SIP signaling group.
When an call is ringing to the Office Communicator user, the caller (either on an Avaya station or a PSTN line routed through the PBX) will not get ring back tone. This issue has been resolved by Avaya with the 5.x software releases.
Quality of Experience reports will not contain information regarding jitter and packet loss.
Comfort noise generation is not supported. As a result, comfort noise is not played on Office Communicator.
ISDN Failover is not supported from an OCS perspective. If the Avaya PBX is being used for PSTN connectivity and multiple T1's are being utilized, an OC client will not retry a call based on a T1 being unavailable. It may be possible to configure the Avaya to not assign outbound calls from OCS to an unavailable T1, but this configuration was not tested.
Summary
So while this may have some issues for 4.x it is recommended by Microsoft to use SES 5.x software to get the best results. If planning to use direct SIP I would recommend thoroughly testing before deployment of the service.
An Alternative Solution
Another configuration that would also be possible is to use a Hybrid Gateway from one of the certified gateway vendors http://technet.microsoft.com/en-us/office/ocs/bb735838.aspx that also supports IP-IP GW features. Considering that some of these vendors have completed interoperability testing with Avaya and Microsoft it may present a more flexible solution with fewer issues.
Avaya OCS Interoperability
I know dual forking is not on the supported list, but are you familiar with anyone configuring Avaya in dual forking fashion?
ReplyDeleteCurrently, no I dont know of anyone that is doing dual call forking (which is only supported with Nortel). If you are refering to dual ringing devices with Sim Ring, yes there are a number of customers doing this. Do you have a specific question on the configuration?
ReplyDeleteNote: Dual forking is a term commonly mistakenly used to describe any time that you try to ring two phones at the same time but it is in fact a feature for dual ringing devices that has feedback mechanisms that stops call looping and is configured on both systems with the same DID. It is currently only supported to do on OCS when configured with Nortel CS1000. Sim ringing or dual ringing is very different in that it is usually only controlled by one system and has no loop prevention but still allows two phones to ring usually with different DID numbers.
In this situation, it would be used initially as a replacement to the Avaya softphone. Since we are not yet replacing Avaya phones with OC endpoints, we need both devices to ring with Avaya handling the call from the PSTN perspective. I think sim-ring would be a better description. In the future, it would be used to phase out Avaya altogether.
ReplyDeleteI have a post that offers advice about doing this but for Cisco deployments but you could apply the same tips for Avaya. http://voipnorm.blogspot.com/2010/01/cucm-and-ocs-ringing-dual-device-tips.html
ReplyDeletehttps://www.avaya.com/master-usa/en-us/resource/assets/applicationnotes/ocs-acm-call.pdf is a blank page
ReplyDeleteRocky19xx@hotmail.com
Hi Rocky,
ReplyDeleteI tested the link and it seems to be working fine.
Hi,
ReplyDeletejust to comment on the OCS-SES integration nightmare: that single "OCS-ACM-CALL.pdf" is really all source of information, that you can find in this subject.
It was written in 2008 so dont expect any updated info regarding OCS R2, no updated info regarding SES 5.x, and I am not mentioning issues like ringback etc.
Agreed its kind of a black hole at the moment. I will try to find some unoffical guidence/ Configuration notes and see what I can come up with.
ReplyDeleteCheers
Chris
I have managed to get my ACM and OCS working with direct SIP using SES.
ReplyDeleteStill working through a couple of issues though, notably I am not getting ring back tones when calling OCS users, despite being on 5.x!
I followed the old Avaya guide for the majority of the setup, there were a few things I had to do on top of what is in there though.
This comment has been removed by the author.
ReplyDeleteHi Simon,
ReplyDeleteI have an idea regarding ringback as this could be related to early media. Take a look at Doug's blog which mentions a work around for Ringback in a similar situation:
http://blogs.technet.com/dougl/archive/2009/07/30/ring-back-workaround-for-ocs.aspx
Cheers
Chris
Thanks Chris, I had a look at that, but I don't think it really applied as it causes the mediation server to send 180 responses when users are offline.
ReplyDeleteIn my case I can see 180 ring messages going from OCS to SES in the SES logs, but the ACM does not seem to be playing those ringback tones to the caller.
Hi Simon,
ReplyDeleteI have been doing some digging. I think your issue is related to early media. I will have a blog post coming out soon on it. But if you have Avaya CM 5.2 you should be able to turn on early media both on the trunk and endpoint and apparently this will fix the issue. Other wise if you can disable Avaya from sending Supported: 100rel this may also fix the issue.
Cheers
Chris
Another year just passed, with definitely no update at Avaya side regarding their documentation... Just an FYI, CM6 is already out, with Avaya session manager, and SES became deprecated. Upgrading the CM5+SES5 to CM6 may be a huge pain for some customers, as the built-in SES5 will break.
ReplyDeleteI have a deployment with Avaya CM5.2.1 SP8/SM 6.0 SP1 with OCS 2007 R2 via Direct-SIP to support 'Enterprise Voice', and we encounterd Ringback issue for the PSTN caller to Enterprise Voice number. And after deep finding it ended up being the 'Avaya Gateway' providing connetivity to CM/SM with Mediation server on which the attribute 'RTP Detect' was not functioning as expected. This is caused because of the temperory link failure which is something that keeps on happening on the Gateway per Avaya, and which we were able to re-produce by dropping ports on network switch manually.
ReplyDeleteAt this point Avaya is working with their product group to develop a patch which will address this issue.... Stay Tuned!
does anyone know is avaya still working on this issue?
ReplyDeleteVarious Avaya support measures ought to be updated along with this development.
ReplyDeleteTechnical support teams which work with Avaya systems should learn about this latest update with their system.
ReplyDelete