At first glance you would say no problem just do a PRI integration using an Audiocodes gateway but because of Port capacity issues and costs the customer chose to use an H.323 integration leveraging a CLAN card.
Audiocodes does not support the Avaya version of H.323 but Cisco ISR/CUBE does support Avaya's version of H.323. Cisco Cube is on the Lync OIP list as well so you would think everything would go smoothly. We managed to get calls back and forth between the two systems but there are several caveats. The remaining part of this blog outlines the issues and why doing h.323 to SIP conversion is not my recommended approach.
1. DTMF - Everyone needs DTMF's and it is supported from Avaya through the Cisco ISR when landing on the Lync Dial in Conferencing Bridge or choosing options when leaving a voicemail in Exchange UM. The issue is with the delay is takes from the CUBE to send the digits to the Lync server. Because Avaya version 3.1.2 appears not to be able to send a timer value within the H.245 out of band signaling for DTMF the Cisco CUBE defaults it 4000ms. Changing DTMF to alphanumeric only provides a marginal improvement. This is expected behavior according to Cisco TAC but the delay is not ideal for end users
2. Caller ID - Caller ID from the Avaya station side does not get passed. From wireshark traces we don't see name of extension number in the from field in the H.245 signaling. Lync rewrites blank from fields with anonymous otherwise users would be confused by seeing the IP address of the gateway.
3. Call Transfers - When an Avaya user calls a Lync user and the Lync user transfers the call back out to an Avaya end point or the PSTN the call drops after 30 seconds. The issue is that the Avaya sends a FIN message and closes the TCP socket essentially severing the signaling and hair pinning of media through the Cisco CUBE. The original calling party still shows the call is connected because once the FIN is sent the Cisco CUBE has no way of providing disconnect supervision as the TCP Port no longer is active.
Caller ID - Wireshark Capture:
Call Transfer Capture:
Call leg numbering:
Frame 4: Setup Request from Avaya to CUBE to establish TCP connection for H.225 signaling. This shows source Port 1720 and destination port 64970
Frame 16407: This is the TCP FIN message received from Avaya. The ports indicates that it’s the same TCP connection as the original H225 connection above. Upon receiving the FIN message, CUBE determines that this call leg’s call signaling is broken, so he proceeds to send SIP BYE to Lync for the 2nd call leg, and the disconnect propagates throughout the rest of the call.
BYE sent to Lync:
However, due to the H225 TCP connection between CUBE and Avaya is the first to tear down, CUBE and Avaya can no longer exchange H225 messages to disconnect the call, which is why we never see Release Complete sent from CUBE to Avaya for the first call leg.
Then about 6 seconds after the initial disconnect, Avaya sent CUBE a release complete for the first call leg, but using a different TCP connection (1720->14108) which is the one used for call leg 4. CUBE is not listening on this port for the first call leg so it did not recognize the release complete message.