ASAI, the protocol between the Communication Manager and the AE Services does not provide very good support for Call Park. This limits the information that TSAPI/JTAPI/DMCC can provide to applications.

If it is available, TSAPI will often attempt to replace information from the Communication Manager with better information it has gathered earlier in the call. For Call Park, some improvements were made in AE Services 6.3.0 which mean that, under some circumstances, you will be able to see the correct Calling number.

To be able to keep track of the call, and return the correct calling number, TSAPI must be monitoring it before, during and after the Call Park.

Example 1: An incoming call to A (monitored). A parks the call. B (monitored) retrieves the call. B's Established event will not contain the Calling number as the call was not monitored while it was parked so the original TSAPI call block was lost.

Example 2: An incoming call to A (monitored). The application starts a monitor on the call. A parks the call. B (monitored) retrieves the call. B's Established event will contain the Calling number as the call was monitored while it was parked.

Martin

Here is an example of how to configure a BCA. In the example below, the 4th button on 40204 is now a BCA of the first (default) call appearance of 40203.

Whenever a call comes in to 40203 on the default appearance, a lamp will wink on 40204 and it can answer the call by pressing button 4.

change station 40204 Page 4 of 5
STATION
SITE DATA
Room: Headset? n
Jack: Speaker? n
Cable: Mounting: d
Floor: Cord Length: 0
Building: Set Color:

ABBREVIATED DIALING
List1: List2: List3:

BUTTON ASSIGNMENTS
1: call-appr 5:
2: call-appr 6:
3: call-appr 7:
4: brdg-appr B:1 E:40203 8:

Bridging is a huge subject and I cannot go into it in detail here. There is a lot of information in various posts on these forums. The archive of these forums from before we moved to the new portal will be available soon so you will be able to search through it then.

In the mean time, you should have a look at the TSAPI Programmers guide. It will give some information of how bridging interacts with TSAPI (and therefore DMCC).

Also, you should use MediaStart events when triggering your recorder. These are directly tied to the RTP stream - Established events are only an indirect indication that media is available.

Martin

I am assuming that your client has an Avaya Aura Communication Manager. In this case, to do any type of CTI, he will almost certainly need an Application Enablement Services. This makes several APIs available which allow a third party application to monitor and control phones.

TSAPI, JTAPI and DMCC would allow you to make calls and receive notifications when a call is received. However, I have a feeling that they may be more heavy-weight than you would like.

AE Services also provides the Telephony Web Service which provides very basic control. This would allow you to make a call but does not support events so it would not notify you of an incoming call.

You don't say what softphone your client is using so I do not know what facilities it provides. I do not think any of the Avaya softphones provide handles for third party applications but I have not tried any of their advanced features so I can't be sure.

Martin

As I said in response to your other question, I think it is possible to configure Experience Portal ports as stations on Communication Manager and monitor them using TSAPI. However, I suspect that it would be possible to transfer data even when the Experience Portal is connected over a trunk.

You may be able to get better information on the Orchestration Designer forum as they may be more familiar with Experience Portal.

Alternatively, you could open a Technical Support Ticket and a colleague may be able to give you better support.

Martin

As far as I know, it is possible to configure Experience Portal ports as stations on the Communication Manager. I believe the correct station type is 7434ND and it should be possible to monitor them using TSAPI.

However, I am not familiar with Experience Portal so I cannot be 100% sure that this is correct.

Martin

The events you receive will depend on:
o What you are monitoring
o When you start the monitor
o What events you selected to receive
o The call flow

For example, say you monitor station A and it is in a call to station B. If B transfers the call to C, A will have been moved to a different call. If you do not monitor for Transferred events, you will not know this until the call is ended.

As for bridging, there are many documents that give information on it. For example, "Avaya Aura Communication Manager Feature Description and Implementation".

Martin

I don't see that I can briefly describe how to handle multiple stations. If you have specific questions, I will try to answer them.

The log shows the AE Services loosing the connection with the Communication Manager and automatically unregistering the phone:

2014-02-12 15.53.42,272 com.avaya.mvcs.station.h323.ras.DefaultTerminalDevice$H323StationProxyImpl timeout
WARNING: [10.100.115.75:12088:0] : CM Connection lost - protocol timeout: MISC timer, tried 3 times.Possible problem(s) include:
1. Network connection is not working or is congested

followed by:

2014-02-12 15.53.42,285 com.avaya.mvcs.station.h323.ras.OutgoingRASHandlerImpl shutdown
FINE: [10.100.115.75:12088:0] unregister reason=CM Connection lost - protocol timeout: MISC timer, tried 3 times.Possible problem(s) include:
1. Network connection is not working or is congested

If your application is monitoring for TerminalUnregistered events, I think it will receive an event when this happens.

You will need to figure out why the AE Services is loosing the connection to the Communication Manager.


Another thing that I should point out is that you are performing a lot of processing (including sending requests to the AE Services) using the DMCC Event thread. You should never do any processing in this thread as it will seriously degrade the performance of your application and can lead to links being dropped.

The only code that should be in your handler callback function is to take the incoming event and place it on your own, internal, queue. You can then service this queue with your own thread.

Martin

My first guess is that you may have Bridge Call Appearances configured on/of one of the phones. This can lead to one phone being in a call even though it is not taking part in the call.

Do a "display station" of the extensions to see if they have a call appearance of another phone. It may also be that some other phone has a call appearance of one of these extensions which may be more difficult to pin down.

Martin

You can use the same session for all extensions.

I do not think there is a forum on Devconnect that deals with one-X Agent. There may be a forum on support.avaya.com where you can get help.

Martin

Exception: java.lang.IllegalStateException: [12088:CMPROD01:10.100.115.75:0] Station is not registered

It looks like you are pressing the button before the station has been registered. It is important that you wait for the RegisterTerminalResponse before attempting any actions on the station.

martin

TSAPI and, therefore, DMCC provide only partial support for bridging. I cannot state what works and what does not work apart from saying that anything that is called out in documentation as being supported is supported. Anything else is undefined.

Maybe the best way of putting it is that there are still cases where the events you receive will not match those that you might expect.

There are no plans to comprehensively rectify the situation.

Martin

It should be possible to SSC a recorder into any stable call once you know the CallID and extension number of one party in the call.

Why do you think there would be a problem?