I need to know like treating the events generated by the TRANSFER

And if event TRANSFERED is just as the call no longer this but in the internal one

Thank you very much

Pablo,
Could you restate your question please. I do not follow it well enough to understand what you are asking about.

Thanks
John

Thanks John to respond


It will deal to be but clear with my question.


I am developing a Recorder and have problems with two things, that are:

1 The handling of the events that come by Transferences that depending the case do not come either always different and if event TRANSFERED is event of aim of call on that telephone. In the case of the events is some efficient method to be able to treat them?

2 Often from the Main one the ANI does not come to me comes characters like these T459#1. is solution?

I hope that of this form more is understood and what I am requesting in general if you could help to find a method basically me to be able to later treat well events TRANSFER and TRANSFERED and HOLD and TRANFER, etc. He is complex this and us this returning crazy.

It is possible to be asked in Spanish?

Thank you very much and it excuses my English.

Pablo,

There are two call transfer scenarios. We refer to them as 'blind' and 'consultative'

In the first
A calls B
B answers
B initiates transfer and calls C
B completes transfer while C is still ringing

In the second
A calls B
B answers
B initiates transfer and calls C
C answers
B completes the transfer

An application must handle both scenarios. Users can do whichever they want. Yes the order of events will be different.

Regarding ANI, (or lack there of). If the call/device is monitored when it first terminats (begins to ring a destination) by TSAPI, then ANI is relibally captured and delivered on subsequent operations (as long as it is not ambigious or 'lost'). If the call is not monitored at the first destination that starts to ring, and is transferred to a device that is monitored then ANI will not be available. This is the typical problematic scenario. The typical work around is to have the call go through a vector that is monitored before delivering it to the destination. This works well in call center environments, but in other environments where steering the call through a vector is difficult does not work. The solution to this second case is to have the application monitor a larger set of stations where the transferring is comming from.

I hope this gives you some insight into the systems operation and allows you to make progress on the issues you are working. Feel free to ask more questions and hopefully I can provide some information you can use.

My spanish resources are on vacation at the moment. However you could ask in spanish and english, and I run your spanish through a translator, and maybe between the translator and the english provide more on target responses. unfortunately until next week the answers are going to be in english.

BTW, your English is much better than my Spanish, so your apology is not needed.

John

Thank John for your answer is very useful.

You could give me to an example in these two scenes the message CTI that would have to come and in case before the Agent makes a Hold and later transfer as she would have to appear this message.

On the other hand the messages change if the Agent this being observed you would also have example of this.

Comunicator Manager 4.0.x and AES 4.0

Thank you very much.