How to configure WAS CEA to use Avaya AES 4.2

We are proud to announce that Avaya's PBX solution, Application Enablement Server (AES) version 4.2, passed all initial interoperability tests with CEA 1.0.0.0. We are successfully able to control various telephony endpoints configured on the AES directly from our CEA 1.0.0.0 enabled application. As with most interoperability tests, there were a few issues that were exposed that had to be addressed. This blog post will serve as an early warning to the greater community of how to get around a major issue we found when inter oping with AES 4.2.

The Avaya AES 4.2 only supports the TLS transport for receiving TR/87 requests. This prerequisite is fine as CEA supports sending requests over UDP, TCP, or TLS transports. However, there is a problem where AES 4.2 does not support "sips:" over the TLS transport. This is a bug in their code and they are working to fix this in a subsequent release. In the mean time, a work around has been crafted to circumvent this issue.

By default, the Websphere Application Server (WAS) has UDP, TCP, and TLS defined as available transports to send data across the network. When CEA 1.0.0.0 constructs a request outbound to a PBX over UDP or TCP it uses the "sip:" construct in the request. This typically denotes that the request is not secured when its sent out over the network.

Example:

Invite Request: INVITE sip:+19194863101@subzero.rtp.raleigh.ibm.com:4723;user=phone;transport=tcp SIP/2.0
From: sip:ibmtest1@9.42.92.132;tag=5109292067337619_local.1249402695153_2_1
To:
Call-ID: 5620596434574489@9.42.92.132
Max-Forwards: 70
CSeq: 2 INVITE
Content-Type: application/csta+xml
Content-Length: 362

However, if you delete a transport channel, WAS will only utilize the remaining transports to send data. We will use this behavior to our advantage.

What we want do is delete the UDP and TCP transport thus only leaving the TLS transport available to send CEA traffic. You can do this by browsing to Application Servers --> Server Name --> Transport chains. You should see a menu like the one presented below.

Select and Delete the SIPCInboundDefault and the SIPInboundDefaultUDP . This will leave you with the SIPCInboundDefaultSecure (TLS Chain).



On the CEA configuration panel where you specify the host, port, and transport of your Avaya AES, you will specify TCP as the outbound transport.



By doing this, the CEA application will construct its outbound request to the AES server using the "sip:" construct. Normally, CEA would attempt to send out the TR/87 request to the AES over the TCP transport you defined on the panel, but since only the TLS transport is available, its forces WAS to send the TCP formatted request over the TLS transport.


Thus, you get a "sip:" constructed request over a TLS transport. This is exactly what the Avaya AES supports.

Example:

Invite Request: INVITE sips:+19194863101@subzero.rtp.raleigh.ibm.com:4723;user=phone;transport=tls SIP/2.0
From: sip:ibmtest1@9.42.92.132;tag=5109292067337619_local.1249402695153_2_1
To:
Call-ID: 5620596434574489@9.42.92.132
Max-Forwards: 70
CSeq: 2 INVITE
Content-Type: application/csta+xml
Content-Length: 362