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

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.

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

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

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.

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

Thanks
John

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

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.

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

So you are requesting that the 'change uniform-dialplan X' form be supported by SMS? Any other forms? Remember that the more specific you are the more likely you are to get what you want/need.

I can not simulate your message with my tools, but upon inspection your are not passing in a sessionID. If this is the initial request, then in my traces using the sms test tool

https://,ip-addr-of-AES>/sms/sms_test.php

I don't see the test application sending a session tag at all.

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://xml.avaya.com/ws/SystemManagementService/2005/04/04" xmlns:ns2="http://xml.avaya.com/ws/session">
<SOAP-ENV:Header>
<ns2:sessionID SOAP-ENV:mustUnderstand="1" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next"/>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:submitRequest>
<model>Station</model>
<operation>display</operation>
<objectname></objectname>
<qualifier>40010</qualifier>
<fields>*</fields>
</ns1:submitRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

On a request where a session has been acquired I see the sessionID in the message:

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://xml.avaya.com/ws/SystemManagementService/2005/04/04" xmlns:ns2="http://xml.avaya.com/ws/session">
<SOAP-ENV:Header>
<ns2:sessionID SOAP-ENV:mustUnderstand="1" SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">f9f39c91227a51d0bded3fbe548a850f</ns2:sessionID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:submitRequest>
<model>Station</model>
<operation>display</operation>
<objectname></objectname>
<qualifier>40010</qualifier>
<fields>*</fields>
</ns1:submitRequest>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Hope that puts you on track....
John

Igor,
The ability to set the text for a button is not supported, unless you take advantage of the IP phone's PUSH capbility whereby a WML page can be sent to the phone. The softkeys alongside of the WML page can trigger actions based on the content of the WML page.

This functionality (WML or IP PUSH) is only available for Avaya IP phones today, and SIP devices in the near future, but not DCP or other multifunction TDM based phones.

AE Services' DMCC API gives lamp update events when the button's lamp(s) change state (which happens for most button types when they are pressed, but not all). There is no provision to get events on button down or up from any API provided by Avaya, other than through the WML capability described above.

John

The answer depends on the nature of the customer's maintenance contract with Avaya or the business partner. In the case of Avaya, if they have purchased SS or SS+U (software support [ plus upgrades] )then as long as the customer has not canceled their service contract, yes software upgrade to 4.2 will be free.

use this file...
/home/admin/xln_S8300_134140_20080124.tar.gz

I will get the document corrected.

If you are unaware of the FAQs, click on the FAQs item in the left panel menu on this page.