Asterisk & Avaya Communications Server using H.323

Asterisk Asterisk Support
1

Environment:

  • H323 Endpoint - Asterisk (v1.2-beta1)
  • Avaya Prologix CM v2.0
  • 4 free IP_API_A licenses
  • Extension configured as H323

We have successfully managed to establish an H323 trunk between the Avaya and Asterisk with two way calls over G711. For other applications we are looking to connect Asterisk station side as a client to the Avaya Gatekeeper.

Whenever I attempt to connect Asterisk via Woomera or ooh323 stacks (also tried the OpenH323 softphone to elminate Asterisk as the core issue) we get a message back stating ‘resourceUnavailable’. So the endpoints are communicating and getting a message back from the Avaya. If we change the extension we are trying to connect to, to an analog station then we get ‘invalidTerminalType’, so indeed it appears to be something to do with either a license or invalid configuration for the station configured as H323 (we also tried 4610 and 4624).

The only place on the Avaya support portal I found a reference to ‘resourceUnavailable’ with an H323 connection was the CMAPI server (we have one connected that works fine with extensions configured as 4624) which stated this happened when you had run out of type A licenses (we have 4 that are free).

Any insight on how to get this configured and working on the Avaya would be greatly appreciated. I believe it is a license issue, where you may need different licenses for H323 Avaya hardware/software phones, CMAPI and ‘pure’ H323 3rd-party hardware/software phones. Any ideas?

Avaya Document on H.323 interconnection

2

If you have an H323 trunk group working between the Asterisk and the CM2, that’s probably all you need.

Add your IP stations to the Asterisk box, and setup their extensions there the same as you would for any Asterisk IP station.

To reach them from the CM2 (by dialing an extension):

  1. Build an aar dialed string. Command: change aar xxx -Where xxx is a 3 digit dialed string that you’ll use for routing. Point that string to a route pattern. (Which you setup next)
  2. Add a route to the trunk group. Command: change route xx -Where xx is an unused route pattern. Be sure to put 3 in the No. Del Digits to strip off the aar string.
  3. Change the UDP to have the system find those extensions at their new location. Command: change udp xxxx -Where xxxx is the extension(s) resident on the Asterisk Box. On the form you can have an individual extenison, range of ten, one hundred, or one thousand numbers follow the aar dialed string route. To have calls follow the dialed string, type “udpcode” in the field next to the extension or group of extensions that you want to be resident on the Asterisk box. Put the 3 digit string you created in step one above in the field that appears.

Now, when you dial any of the extensions on the Asterisk box from the Avaya box, the call will route to the Asterisk box directly over the h323 trunk group, and should ring the station with the same 4 digit extension.

None of this will work however, if your customer options do not include “Uniform dialing plan - Y”. Do a display system-parameters customer-options command and check on page 2 before you start (to be sure).

3

[quote=“dufus”]If you have an H323 trunk group working between the Asterisk and the CM2, that’s probably all you need.

Add your IP stations to the Asterisk box, and setup their extensions there the same as you would for any Asterisk IP station.

To reach them from the CM2 (by dialing an extension):

  1. Build an aar dialed string. Command: change aar xxx -Where xxx is a 3 digit dialed string that you’ll use for routing. Point that string to a route pattern. (Which you setup next)
  2. Add a route to the trunk group. Command: change route xx -Where xx is an unused route pattern. Be sure to put 3 in the No. Del Digits to strip off the aar string.
  3. Change the UDP to have the system find those extensions at their new location. Command: change udp xxxx -Where xxxx is the extension(s) resident on the Asterisk Box. On the form you can have an individual extenison, range of ten, one hundred, or one thousand numbers follow the aar dialed string route. To have calls follow the dialed string, type “udpcode” in the field next to the extension or group of extensions that you want to be resident on the Asterisk box. Put the 3 digit string you created in step one above in the field that appears.

Now, when you dial any of the extensions on the Asterisk box from the Avaya box, the call will route to the Asterisk box directly over the h323 trunk group, and should ring the station with the same 4 digit extension.

None of this will work however, if your customer options do not include “Uniform dialing plan - Y”. Do a display system-parameters customer-options command and check on page 2 before you start (to be sure).[/quote]

Interesting approach, I will look into it and see if it satisfies the requirements. What I am attempting to do is use the ‘single step transfer’ capability of the Avaya via the TSAPI/CT interface which requires an ‘extension’.

Do you think this setup will support that? Nonetheless I will look into this and post the results. Thanks.

UPDATE

I reviewed how we did the H323 trunk integration and we used ARS to create a single digit to select the H323 trunk group followed by the dial string. The dial string then equated to an extension on the Avaya (although we created them dynamically at that stage).

The issue is that you may not monitor these ‘extensions’ via the TSAPI/CT interface of the Avaya, which is what is needed for the application using the single step transfer capability of the Avaya.

So I believe we are back to getting the H323 Extension/Gatekeeper working to do a station side connect of the Asterisk to the Avaya.

Further ideas? I really think this is a license issue on the Avaya, we just can not seem to find any details on this point.

4

So, when you say “monitor”, do you mean “service observe” or do you mean “report the state of” as states would be known by any standard Avaya CTI interface? (Like the old MAPD or Callvisor)

Are these extensions to be part of a split/skill group? Are they going to provide an IVR or call recording functionality? (Or something like it?)

5

It is the latter, monitoring using the TSAPI/CT (CSTA interface) which reports the state of the extensions/agents, so that we may see all of the events related to that extension.

A recording function that would be ‘invisible’ to the caller/agent on the Avaya. This may only be acheived with the single step conference, as with the other approach there would be an interruption as the 2 step conference puts the caller on hold to connect to the line. Plus there is no way to monitor the state of/control the extension (receive events via TSAPI) unless it is an H323 Avaya extension.

6

You might hate me for saying so, but, I don’t think this is a good application for a VOIP solution.

I’d take a different route for this…

Get a Digium T1 card, and a standard DS1 for the CM2.

Build the DS1 normally on the Asterisk side, but, on the CM2, build a group of single line stations that would be defined as DS1FD. (Instead of, say, 2500, 4610, 7410, etc…)

Put all the DS1FD stations into a hunt group and set the hunt group as AAS =Y (Auto Available Station).

Now you have two options…

  1. You can have the agents conference the hunt group lead number, with incoming calls immediately begining recording.

or (and this is what I’d do)

  1. You create a web application that the agents themselves would control, and just setup the DS1FD stations to be able to service observe the agents.

The agents would have a simple browser/java/whatever app running on their desk. Their login to the application would tell the Asterisk server, “When I click this button, use ZAP/G1 to dial the service observe feature code and my extension, and begin recording what you hear.”

The agent would only have to click one button, and the calls wouldn’t even be inturrupted by a conference event. Service observe could begin anytime and end anytime.

When the agent clicks the stop button, the file would be stored with the date, time, and agent information. (Making retrieval and playback easy.)

You wouldn’t even have to put it in a hunt group if you choose option 2.

If you want invisible, that’s how to do it.

Conference wouldn’t be invisible. The callers would hear a moment of silence or music on hold as the recording extension is added to the call.

7

Indeed, the whole point of this approach is to eliminate the need for any hardware on the Asterisk/DS1 on the Avaya and use VoIP. We already have this working with a Dialogic platform and also have H323/VoIP working with the Avaya CMAPI system (but CMAPI uses the same extension type as an Avaya 4602 IP Phone, not a ‘pure’ H323 extension). Indeed most major recording platforms are moving to VoIP solutions, as this is a scenario ripe for VoIP.

Ultimately it would be great to do this with SIP, but the current Avaya platform does not have a combined SIP Proxy (seperate S8500 server, etc) as that is a few months away. In the meantime, we are looking to do H323 as of course the Asterisk provides the normalization of SIP/H323 in terms of any application features so the effort may be moved to SIP once we have it.

I am convinced this may be done with H323 extensions on the Avaya, but no one seems to be able to provide a clear answer on how to enable this on the Avaya. I am still convinced it is a license issue and that you need a license besides IP A or B. Any ideas on where to find this? As Avaya just sent us the H323 compatibility doc above.

8

A quick look through the doc tells me that this probably isn’t a license issue.

From the linked document:

GatekeeperReject ::= SEQUENCE --(GRJ)
{
requestSeqNum RequestSeqNum,
protocolIdentifier ProtocolIdentifier,
nonStandardData NonStandardParameter OPTIONAL,
gatekeeperIdentifier GatekeeperIdentifier OPTIONAL,
rejectReason GatekeeperRejectReason,
…,
altGKInfo AltGKInfo OPTIONAL,
tokens SEQUENCE OF ClearToken OPTIONAL,
cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL,
integrityCheckValue ICV OPTIONAL
}
requestSeqNum this value is set the requestSeqNum value received in the GRQ.
protocolIdentifier H.225.0 version
rejectReason contains the reason for the rejection and is coded as follows.
GatekeeperRejectReason ::= CHOICE
{
resourceUnavailable NULL,
terminalExcluded NULL, – permission failure, not a resource
failure
invalidRevision NULL,
undefinedReason NULL,
…,
securityDenial NULL
}
Where:
ResourceUnavailable There is no valid RAS address specified.
TerminalExcluded There is no valid alias address specified.
InvalidRevision Not used.
UndefinedReason Gatekeeper internal error.
SecurityDenial Not used.

You’re putting in the C-Lan board thats controlling the 46xx station, as the resource to register with on the Asterisk side, correct?

P.S. Still think this is best done TDM…

9

No, we want to control an H323 extension type, not a 46XX extension type.

Then why has Avaya come out with CMAPI for VoIP recording on the Avaya? Going forward using TDM is simply an additional cost, no reason not to use VoIP.

Now, trying to use H323/VoIP as opposed to SIP/VoIP may be an issue…

10

In my humble opinion, VOIP is just a way for Avaya and everyone else on the VOIP bandwagon to quit having to develop, manufacture, and support “big iron” hardware.

VOIP is cheap, and the margins for selling it are high when compared to TDM solutions built from scratch.

Of course they’re developing VOIP recording systems. They sell VOIP platforms, and need to sell products that match their customers enviroment.

(Getting on the soapbox now… stop reading whenever you feel like it.)

Sadly, as you are coming to find out, there are flavors of VOIP out there that don’t play well in the same sandbox. Until the real solid standards are created (and more importantly adopted) there’s going to be tech issues for people like you and me. It may (or may not) surprise you to know that there are no FCC functional standards for VOIP equipment sold in the US. The crummy analog phone in your kitchen has to meet more operational standards, than your VOIP phone does, to be sold.

You don’t really gain anything from moving your platform from TDM to VOIP. VOIP, after all, is just the transport method for the noise leaving my mouth on the way to your ear. A 10/100 Ethernet port carrying my digitized voice isn’t significantly different from an Avaya DCP digital port carrying my digitized voice. It’s just different wires taking a different path. Ultimately they end up in the same place. (Your ear.)

Your recording application, while it may be a VOIP solution, will not be superior to a TDM solution. It won’t be worse, but ultimately, it can’t be made to be better either. There’s only two things you can do with voice after all; Hear it live, or Record it for later. With variations of a theme, that’s it, and it doesn’t matter if it’s TDM or VOIP that did it.

I favor TDM only because it has solid communication standards, minimizes the functional objects (reducing failure points), and superior sound quality. Your opinion, of course, may vary.

(Off the soapbox now)

Check with Avaya engineering. They’re very good at creating development platforms and development kits. They might have something useful for you for a VOIP development effort. If this is a mission critical business system, you’ll want it to be dependable.

11

Of course we could debate the merits of TDM vs VoIP, but our views differ significantly and the middle ground may be minimal. So, I won’t stand on my soapbox but I do appreciate your insight.

Back on focus. I will continue to trace what the issue is, as there are claims out there that folks have gotten Netmeeting and other H323 apps to work fine with Avaya on the station side as required, so there is no reason ooh323 or chan_woomera should not be able to do this. If anyone has any additional recommendations on this by all means please post. Otherwise I will report back once successful.