Message |
[+]
Device, Media and Call Control (Archive - Oct 2013 and earlier)
» Service observing help?, 28/05/2008 07:11:18
» Go to message
|
|
Sorry, There is no sample code available that demonstrates this approach.
The typical application's behavior is to use the provisioned feature access code to activate SO to an specified extension, and then wait for calls to occur. (or wait for a call then activate service observing using the FAC). This should be a fairly straightforward modification to the Simple Call Record sample code that is part of the .NET SDK (assuming you want to work in C#).
John
|
|
[+]
Device, Media and Call Control (Archive - Oct 2013 and earlier)
» Service observing help?, 27/05/2008 08:05:29
» Go to message
|
|
There is a description of how to utilize various CM features to achieve call recording solutions under the following FAQ title:
How would an application go about recording a call at specific device?
On this page (log into the portal and then change the URL to this link):
https://devconnect.avaya.com/secure/faq/d_faq.jsp?f=1
If that is insufficient, please post additional questions.
John
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» issue with dem, 27/05/2008 07:59:11
» Go to message
|
|
Thibault
If you could enter this question via a tech support ticket we can direct the question to resources that can help you with your question. We do not have any DEM knowledge within the team that handles the AES forums.
John
|
|
[+]
Device, Media and Call Control (Archive - Oct 2013 and earlier)
» DMCC work with softphone?, 27/05/2008 07:47:08
» Go to message
|
|
What release of AES and CM are you working with at the customer site?
What method do you use to register (registerTerminal or registerDevice)?
What Media Control and Dependency Mode do you use to register with?
Release 3.X and 4.0 of DMCC does not support DMCC registrations agains IP Softphones due to an internal CM limitation. With release 4.1 of AE Services and CM 5.0 using Media Control == No Media and Dependency Mode == Dependent you should not have the problem you are describing. Denendency Mode == Independent is also supported for this configuration.
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» Does AES suport Attaching Client specific Data, 23/05/2008 09:49:35
» Go to message
|
|
Genesis stores data in its call database. It does not provide it back to CM. When the call re-appears somewhere else, Genesis makes the data available to the application when it queries for it.
At the back end Genesis communicates with the AES to get some call data (calling, called party), and call events (delivered, established, conferenced, etc)
To achieve the equivalent with AE Services a piece of middleware would need developed to cache the information such as customer name, address, account info, where it can be retrieved later as the call is delivered to an agent.
|
|
[+]
Device, Media and Call Control (Archive - Oct 2013 and earlier)
» Delivered event is not reported when extension has call forwarding on no replay configured, 23/05/2008 08:46:40
» Go to message
|
|
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.
|
|
[+]
Device, Media and Call Control (Archive - Oct 2013 and earlier)
» Delivered event is not reported when extension has call forwarding on no replay configured, 23/05/2008 08:39:03
» Go to message
|
|
I believe Ilana is referring to the call forwarding on no reply that is provisioned on the station form.
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» JTAPI- CallObservationEndedEnv (TSAPI_Simultaneous_User License not getting released), 22/05/2008 10:05:07
» Go to message
|
|
This is problem a known issue with the 4.1 JTAPI SDK that will be fixed in the AES 4.2 JTAPI SDK which will be released at the end of May 2008. Thank you for bringing this to our attention.
During my testing the license is released when the application properly shutdown and closed its socket with the AE Services server. It was not necessary to restart the AE Services server (or TSAPI service) to achieve release of the license.
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» AES 3.1, 20/05/2008 18:03:15
» Go to message
|
|
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
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» does AES/CM supports CALEA standard, 20/05/2008 15:57:16
» Go to message
|
|
Avaya does not provide a CALEA interface.
It appears that PlantCML does from the information provided in the find a solution/service search available on the devconnect site. There may be other vendors that provide a call recording solution (e.g. Red Sky, Verint/Witness, NICE, etc), that do as well, however I have no knowledge of that. You would need to contact their sales organizations for further information. I can only report on what is made public through the devconnect site.
John
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» does AES/CM supports CALEA standard, 20/05/2008 12:08:18
» Go to message
|
|
Ilana,
You are going to help us out with some clarity on this question. CALEA is a big thick document with many many requirements. If you are talking about lawful intercept? or some other aspect of the document. Further, support can be at many levels. You can get call information through DMCC or TSAPI. Through DMCC you can gain access to the media stream for a call. These can be done un-obtrosivly. However it has been a long time since I read through CALEA spec. I do not recall if all of the requirements therein can be met.
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» AES 3.1, 19/05/2008 18:05:26
» Go to message
|
|
Pablo,
Could you restate your question please. I do not follow it well enough to understand what you are asking about.
Thanks
John
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» CVLAN vs DLG vs TSAPI, 19/05/2008 09:53:11
» Go to message
|
|
Finally Avaya does not recommend starting a new application using CVLAN either. We would recommend using TSAPI or JTAPI as the starting point for new development work.
Thanks for your interest/question.
John
|
|
[+]
AE Services General (Archive - Oct 2013 and earlier)
» CVLAN vs DLG vs TSAPI, 19/05/2008 09:50:50
» Go to message
|
|
Think of DLG, CVLAN, and TSAPI as a progression in time of the same core set of ASAI capabilities.
Since applications were written to DLG it continues to be supported, however we do not recommend starting new development using this interface. You will spend a lot of time implementing drivers that are alreay built with CVLAN and TSAPI.
CVLAN was built to provide these libraries and simplify some of the complexities that arise from dealing with the protocol level interface that DLG provides so developers could concentrate on building the app and not on the interface to Communication Manager (well back then Definity).
TSAPI is also built on top of ASAI, but provides conversion from ASAI to CSTA (international standards). It provides a similar set of services that the propritary CVLAN interface provides.
Just to complete the story, JTAPI is built on top of TSAPI (which provide a C language interface) and provides a similar set of services that TSAPI provides through a Java API.
|
|
[+]
AE Services Web Services: Telephony and SMS (Archive - Oct 2013 and earlier)
» Uniform Dial Plan, 19/05/2008 09:35:52
» Go to message
|
|
Per our phone conversation, I will enter an enhancement request for the UDP releated forms you need to be supported to the SMS development team.
John
|
|