I do expect this kind of behavior when unconditional forwarding is configured but in this case I configured forwarding on "no replay" on wxtension 40021. 40020 calls 40021 and I am monitoring both. 40020 gets originated event. 40021 does not get any events while ringing if I pickup on 40021 befire the call is redirected get established on both but if the call get forwarded I don't get any event on 40020 which is being monitored

duplicated please delete

Ilana,

This forwading you mentioned is done via coverage path with cover on "Don't Answer" = y for X number of rings or you are using some other feature?

Some traces will be really helpful.

Thanks.

I believe Ilana is referring to the call forwarding on no reply that is provisioned on the station form.

yes I configured true cm "change station " 3rd page
What kind of traces ?

I am going to escallate this into ASAI development as my initial impression is this is a problem with CM. The AES is not receiving ASAI events in this call scenario.

Upon escallation I found that this issue was first noticed in March 2008. In the ASAI technical reference it indicates this is an unsupported feature interaction. At the moment the issue is listed as a possible enhancement in the list of ASAI related feature enahncements that have been requested.

"The Alerting Event Report is not sent in these cases:

. For calls that connect to announcements as a result of ACD split forced announcement or announcement vector commands.
. When an ASAI-monitored call reaches a converse vector step, the ALERTing message sent to the ASAI host will include an optional cause (CS3/23) to inform the ASAI
host that the call has been routed, using the converse vector step.
. For auto-answered stations.
. For stations that have call forwarding busy/DA or All activated using ASAI or FAC."

Hi John
This is a big problem for us. This mean that I might not be able to use callcontrol events and will have to go back to interpreting the lamps and buttons to build my own call control which I was really hoping to escape since it has it's own disadvantages and it's a lot of extra work. Is tere a work around for this that I could use?
any estimates on when the issue is going to be resolved?
Thanks
Ilana

understood, this makes any CTI app for devices where this feature is configured and active problematic.

The work around is what you describe (on some scale). Discover the call appearances using physical device services get button info, and then monitor the call appearance lamp changes on those buttons. If you don't get a timely callDelivered event, poll for status using snapshotDevice.

This 'enhancement' is in the work queue. The priority for 5.0 is high availability for AE Services. Other work may slip in, but at least for the next major release this item is not presently planned to be addressed.

John

The problem I have with using the lamp events is that I can never associate the button with the call . so lets say there are 2 buttons flashing and call deiver comes in I don;t know for which button that call belongs. This is a big hole in my app. I can only associate connected call since there is only going to be one button which has stead green lite on.
Any help on that ?

How 'expensive is getdevicesnapshot?
Can the response somehow be associated with call appearance buttons? are the calls in the response sequential to the call appearance ? Will the first 2 call in snashotresponse correspond to 2 first appearance buttons?

Thanks

"The work around is what you describe (on some scale). Discover the call appearances using physical device services get button info, and then monitor the call appearance lamp changes on those buttons. If you don't get a timely callDelivered event, poll for status using
snapshotDevice. "

Does this means that call control event will be after physical device event?

Ilana
I have been told (althought I have never tested -- and I would do some tests before proceeding), that the order calls are provided in the snapshotDevice response is the order that CM provided the calls to the AES. Thus it is a function of when the calls encountered monitored devices.

To test this out, monitor device 1000 and 1001
offer call A to device 1000
call B to device 1001
answer call A and transfer it to 1001
do a snapshot device on 1001

Note that you can do a snapshot call and get more info after your snapshot device. In the response is calling party number. Aligning the calling party number in the snapshotCall up with the number provided as part of display information in physical device services can help correlate the two pieces of information.

Note further that the snapshot call has state information per party. The number of times I have had two ringing calls on my phone simultaneously is but a handful per year. I would hope that with these tools you can implement an algorithm that is fairly reliable in far less time than waiting for the enhancement to fully support CTI (ASAI/TSAPI/DMCC) from Enhanced Call Forwarding may be.

I realize now that there is a flaw in this line of thinking.... the snapshot device will report only what the AES knows if there is a monitor active on the station. Thus the response will report no information for the ringing call.... test this out. I suspect you will find what I suspect is true.

To answer today's question. the call control service is not going to be triggered. so physical device event (lamp update - flash) will come, but nothing further will come until the app does a snapshotDevice, and then a snapshotCall (if the call id is even reported in the snapshotDevice).

John

Thanks John I will test it out.
What I meant with today question is if I can reallt trust that the call control events are going to come after the physical device event. Can I really assume that if I got lam flushing then after that I am suppose to get call delivered and after the lam changes to steady I get established and not that I will get established event and after that lampupdate to steady?
This will help me design a hybrid call control that consist of physical device and call control events. I think I can only only safely assume that only connected call is a relly indication of connection of the steady lamp and connected call.

I'd guess that they are ordered that way in the 98 percentile, but not 100th percentile. The reason being is as follows

When CM offers a call to a device, it first sends out the lamp and ringer changes. These events are forked and sent to the AES. The AES receives these events, repackages them into CSTA XML events, and sends them to the monitors of that device.

About the same time that CM is sending the lamp and ringer changes to its device driver, it is notifying ASAI services in CM that a call delivered event occurred on a monitored device. The ASAI process runs, and packages up an event to send to the AES over potentially different hardware interface. When the AES gets this notification, it in turn notifiess DMCC, which notifies the monitors of that device. The ASAI/TSAPI traffic is taking a different (longer) path, however as we all know longer is not necessarily last to arrive. So while I would anticipate it will usually be last, I can not guarantee it.

Sorry?.