I'd really appreciate if someone could reply to my question above, thanks!

I have a question regarding the connect String that's been used in the code above (I've read the JTAPI programmers manual, but cant figure it out)

The manual says:

The format of the String is “<tlink>;login=<loginID>;passwd=<pw>;servers=<server entries>”
Where server entries follows the format
<AES_IP_ADDRESS1>:<TSAPI_SERVICE_PORT1>,<AES_IP_ADDRESS2>:<TSAPI
_SERVICE_PORT2>


The <tlink> contains the (unique) server hostname of the AES server, which will map to a unique IP.

If that is so, what is the point of being able to specify multiple server IPs/hostnames in the 'servers' parameter?
(Isn't a given tlink only going to exist on 1 server?)

Thanks

Is it possible to develop a JTAPI app that will somehow monitor a given VDN, and if a call arrives on that VDN, take "control" of it, and do the following:
- read the UUI of this incoming call
- execute the LucentCall.disconnect(xyz, uui) method to disconnect the call, whilst specifying the UUI

The intention is to receive any call that comes in on this VDN, and then just disconnect it by executing the disconnect(uui) method, so that the UUI is explicitly updated via TSAPI mechanisms.

Thanks

I have a CTI app that uses the ListenHold method in the jtapi/TSAPI API

I'd like to convert this CTI app to a Java breeze snap-in - is there an equivalent method in the breeze API?
If not, is there an alternative way to achieve similar results?

The idea is to block audio paths (specifically dtmf, and possibly speech also) to particular parties in a conference (the conf may be held either on Communication Manager AMS or Breeze AMS, that doesn't matter)

Thanks

Is it possible in a VXML app (using the parameter aaiexpr) or in a CCXML app (using the parameter aai) to set the UUI when doing a disconnect?

Most examples generally only show how to set the UUI on createcall and transfer.

However CTI apps can also set the UUI on a disconnect step (for example JTAPI class LucentConnection has method disconnect with param UUI)

Is the same possible in an AAEP app (either in CCXML or VXML)?

As per the CCXML spec, the <disconnect> tag accepts hints. So if I create a hints object with AAI in it, is that expected to work?


Thanks

Reading through this forum on the topic of HA capability for JTAPI apps, it seems that it is the app's responsibility to provide it.

If the initial AES that was used by the JTAPI app goes down, it is up to the JTAPI app to try and connect to another working AES , and then re-register all listeners (essentially, start from scratch!). This can be a tedious exercise, so I am looking for an alternate way.

1. It seems that the AES MPHA setup will provide a seamless failover experience to the JTAPI app (preserves state, and uses virtual IP). Also the White Paper clearly states under MPHA: "In the future, the TSAPI and JTAPI SDKs will re-establish these sockets upon a socket failure and preserve the previous session. It will also launch an audit and recover from the lost state in the AE Services VM.").
So would it be fair to say that with the MPHA setup specifically, the JTAPI app can receive full-HA service from AES??

2. The MPHA setup itself is a large task, and is not possible in Avaya Aura 7 (no System Platform available), or if the site has an all-VM setup. So if there are 2 independent AESs available, is the following possible/recommended:
the JTAPI app obtains a Provider from *both* AESs on startup, and all listeners are registered to both Providers. The JTAPI app will receive 2 events for every single logical event, and it needs to use only 1 stream (till it dies, at which point it uses the other one).

Any comments appreciated, especially around option 2 above.

I've read the AES HA white paper and scoured through this forum as well for related info.

The replies above state that if the initial AES that was used by the JTAPI app goes down, it is up to the JTAPI app to try and connect to another working AES , and then re-register all listeners (essentially, start from scratch!). This can be a tedious exercise, so I am looking for an alternate way.

1. It seems that the AES MPHA setup will provide a seamless failover experience to the JTAPI app (preserves state, and uses virtual IP). Also the White Paper clearly states under MPHA: "In the future, the TSAPI and JTAPI SDKs will re-establish these sockets upon a socket failure and preserve the previous session. It will also launch an audit and recover from the lost state in the AE Services VM.").
So would it be fair to say that with the MPHA setup specifically, the JTAPI app can receive full-HA service from AES??

2. The MPHA setup itself is a large task, and is not possible in Avaya Aura 7 (no System Platform available), or if the site has an all-VM setup. So if there are 2 independent AESs available, is the following possible/recommended:
the JTAPI app obtains a Provider from *both* AESs on startup, and all listeners are registered to both Providers. The JTAPI app will receive 2 events for every single logical event, and it needs to use only 1 stream (till it dies, at which point it uses the other one).

Any comments appreciated!

Martin,

I've looked through this trace file carefully. It contains "monitorCrossRefID 1" and "monitorCrossRefID 2" - this is for both a working case and an error case. So I haven't quite been able to verify what you've asked below.

However I am positive that my app code only executes Call.addCallListener once (and also executes provider.addProviderListener once).
:?: Also because the app works approx. 80% of the time anyway, it just intermittently breaks.

One more thing I can confirm is that my app is receiving what I believe are "rogue" events.

Is the following assumption is correct - for any non-meta-event received by my app, if I execute:
<non-meta-eventObj>.getMetaEvent().hashCode()
the hashcode value returned must also be returned by running <meta-event>.hashCode() for at least one of the 'start' meta events that my app has received.

In other words, I receive a connectionEstablishedEvent for which when I execute arg0.getMetaEvent().hashCode(), I receive a value say 12345. Also for every 'start' meta event that is received by my app, I log the hashcode of the meta event object itself (within the multiCallMetaMergeStarted / singleCallMetaProgressStarted methods)

However for the "rogue" connectionEstablishedEvent event, I have never actually received a starting meta event object with a hashcode of 12345.

At this stage I am just trying to establish whether the issue exists in the JTAPI/TSAPI on the server side and not in my app... is this possible in your experience?

Any advice appreciated!

Martin,

thanks very much for your reply.

I am not that familiar with the format of this trace file.... could you please provide a sample of what I am supposed to be looking for? or maybe point to a doc that explains this file's format/contents

Also, when you say that my app "has started two monitors" - is that the same as adding a callListener? if not, how else does an app start a monitor?

Thanks!

I have an JTAPI thick client application that has been working OK for quite some time (It obtains a Terminal and place a consult call from it to a 3rd party, and then conferences in the old call into this new consult call)

I use MetaEvents in an identical fashion to the sample AgentView app, and this works OK. I trap the events that indicate things like -
1. consult call successfully connected (then perform conference function),
2. conference call successfully completed (then perform other subsequent actions to the conference).

Intermittently - generally once a day, or when I switch between using hard to soft phones - I still haven't managed to find the exact conditions/cause - the JTAPI client starts receiving "duplicate" meta and enclosed events.

*ALL* attributes of the CallControlConnectionEvent received are identical, but the event object itself is different (they have different hashcode values). Printing the following values for the CallControlConnectionEvent object 'arg0' dumps the same value except for the event object's hashcode:

arg0.hashCode() <--- this is the only one that is diff
arg0.getCallingAddress().getName()
arg0.getCalledAddress().getName()
arg0.getConnection().getAddress().getName()
arg0.getID()
arg0.getMetaEvent().getID()
arg0.getCallControlCause()
arg0.getMetaEvent().getCause()
arg0.getConnection()
arg0.getConnection().hashCode()
arg0.getCause()
arg0.getNumberInQueue()
arg0.getDigits()

This breaks the application completely. If I restart the AES server it generally seems to fix the issue. This is AES 6.3.0

Has anyone experienced anything like this before?

I have an app that does the following:

1. for an existing call in TALKING state on my TerminalConnection, place a consult call to IVR (and add my app as CallListener to this call)
2. Wait for consult call to be answered
3. If point 2 above is successful, execute a conference between the held call and new call to IVR

I need to capture the event(s) that indicate points 2 and 3 above have been successfully completed. How can I do that?

For point 2:
I am guessing I need to capture the connectionEstablished (ID 356) event for the connection pertaining to the IVR side....?
However is that enough? What about the MetaEvents received?

I am receiving the following events:
A. singleCallMetaProgressStarted [ID 210 SINGLECALL_META_PROGRESS_STARTED]
B. CallControlConnectionEvent connectionEstablished [ID 356, MetaEvent ID 210, MetaEvent Cause 100]
C. singleCallMetaProgressEnded [ID 211 SINGLECALL_META_PROGRESS_ENDED]

I would appreciate a code sample that demonstrates how my app can conclude that point 2 is 100% complete.

For point 3: Same questions as above. Which events guarantee that the conference has been completed successfully, and how can I capture them including the related MetaEvents?

Thanks!

I have a JTAPI app that does the following: whenever it receives an incoming call , it consults and then conferences another party.

Once this 3 party conf is established, I need to "lock down" this conference i.e. stop any other parties from being able to join it.

What is the easiest way of doing this?

Thanks

Consider a TSAPI/JTAPI desktop application that originates an outbound call to a SIP connected AAEP (or any other particular SIP entity). TSAPI assigns a dynamic string (e.g. T0001#1) to the ‘Device ID’ for this connection.

Since this dynamic string is only valid for the duration of the call, and TSAPI may use different dynamic identifiers to represent endpoints connected to the same actual trunk at different times -
it doesn’t seem feasible to use this to correctly identify connections going to a particular AAEP (or any other particular SIP entity)

Is there a way to guarantee that TSAPI will use a unique identifier to represent an AAEP instance (so that the app can distinguish if AAEP was on the line)?

For example if the app calls AAEP1, then use Tnnnn#1; if the app calls AAEP2, then use Tnnnn#2

Thanks

As mentioned in the Programmers guide and other threads in the forum, using this Selective Listen Hold feature requires an Advanced TSAPI License.

Does this mean that I need 1 Adv TSAPI license per agent station that is going to execute JTAPI listenHold method?

Thanks

In a CS1K and AML connected AACC environment:

I have an AAEP application that sends a call into AACC via Landing Pad along with attached data (just a single numeric value called “UID”)

I understand that this attached data will become an intrinsic value for the call.

My question is – once this call lands with an AACC agent, how can the agent desktop access this UID?

1. Will it be available via any of the CCT Web Service methods like GetIntrinsics or GetAttachedData?

2. If the agent machine was running AAAD, can a screen-pop be done that uses this intrinsic value UID? (the customer may be running a custom desktop client so AAAD may not be available)

3. Any other methods?

Thanks