AFAIK, GenerateTelephonyTones causes a Single-Step Conference recorder to hear the same warning tones as a Service Observer would hear. It is not possible to change these during a call or for an individual recorder/agent. There are several settings on CM that control whether a waning tone is played and how it sounds. Please note that these configurations are global - they affect all stations on the CM.

On page 11 of "change system-parameters features", the "Service Observing" parameter can change the tone played. It can be None, Warning Tone or Conference Tone. By default, for Base Tone Generate Set 1, these are:

Warning tone, the system generates a unique 2-second, 440-Hz tone before an observer connects to the call. While the call is observed, the system repeats a shorter version of this tone every 12 seconds.

Conference tone, the system generates the conference tone before an observer connects to the call. The system does not repeat the conference tone during the call.

Other countries may use a different Base Tone Generator set so they may be different.

You can change how these tones sound using "change tone-generation". For example, I must have played with this feature at some stage as page 2 of my settings looks like:

Tone Name        Cadence        Tone

                          Step    (Frequency/Level)

    conference              1:     330/-8.0           Duration(msec): 200

                            2:     silence            Duration(msec): 2000

                            3:     goto                         Step: 1

Martin

I don't see any issues with what you are sending. If you look that DMCC traces on AES, it is likely to show an Exception which would have more information. There are instructions on how to configure and view DMCC traces in the FAQ "How can I monitor the XML being sent and received by the AE Services Server (debug, log, trace)?"
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/dmcc/index.gsp?tab=other&accordion=faq-60

Martin

As I said previously, you must register the terminal before you can use GenerateTelephonyTones . You have not done so.

Martin

I checked this out using the DMCC Dashboard and it seems that GenerateTelephonyTones is a little bit odd in that, even though it is a CallAssociated function, it requires a First Party Device ID. The device ID must represent a DMCC terminal that has been registered.

You should also note that, if you call CallAssociated.GenerateTelephonyTones DURING a call, it will not take effect until the next call starts. So, I suggest that you call CallAssociated.GenerateTelephonyTones when you get the response to your RegisterTerminalRequest. You will then get warning tones for every call that terminal records.

Martin

Hi Ram,
Not all events contain UUI and/or UCID, even though the SDK may have the infrastructure in place to transport them.

Call Control functions are provided via TSAPI so you must consult the TSAPI Programmers Guide "TSAPI for Avaya Communication Manager Programmer's Reference" to see what is available. You can download this document from the Devconnect website or google the name. There is generally a new version for each release of AES but TSAPI doesn't change very often and the doc is quite good a showing when features were added - any version after 7 should be useful to you.

For the events you mentioned, I used version 7.1.1 of the guide to see whether or not they supported UUI or UCID. Below is a summary. I tested (AES 8.1.3) several of these events and my results matched the document:

OriginatedEvent
- UserInfo = not supported by Communication Manager
- UCID = no
EstablishedEvent
- UserInfo = yes
- UCID = yes
ConnectionClearedEvent
- UserInfo = yes (but CM only sends UUI if it is contained in a ClearConnection request)
- UCID = no
DeliveredEvent
- UserInfo = yes
- UCID = yes
ServiceInitiatedEvent
- UserInfo = no
- UCID = yes
ConferencedEvent
- UserInfo = no
- UCID = yes

The code I used to test looks like the function below. It's basically the same for all events;

public void delivered(DeliveredEvent event) {    

  UserData ud = event.getUserData();

  String UUI = "null";

  if(ud != null)

    UUI = new String(ud.getString());

  String UCID = "empty";

  if(event.getCallLinkageData() != null &&

     event.getCallLinkageData().getGlobalCallData() != null &&

     event.getCallLinkageData().getGlobalCallData().getGlobalCallLinkageID() != null)

    UCID = event.getCallLinkageData().getGlobalCallData().

                        getGlobalCallLinkageID().getGloballyUniqueCallLinkageID();



  System.out.println("Delivered " + UUI + "   " + UCID);

}

The basic steps are:

1. Setup a development environment (usually Eclipse) so you can compile and run the sample code.
2. Configure a H.323 Station on Communication Manager with "IP Softphone Enabled". You will use this as the IVR number.
3. Edit <SDK>\examples\resources\simpleIVR.properties

- callserver = It looks like this should be set to the name of the Switch Connection that AES uses to connect to CM. You can see this using the AES Web Manager (menu "Communication Manager Interface -> Switch Connections").
- extension - the Extension number of the IVR Station from step 2.
- password = the security Code of the IVR station
- cmapi1.server_ip = IP Address of AES
- cmapi1.username/password = a CTI user configured on AES
- cmapi1.server_port/secure = I recommend setting this to 4721/false . You will then use the insecure DMCC port and save a lot of messing with certificates.

4. Assuming you will use the insecure DMCC port, use the AES Web Management interface to enable the insecure DMCC port (4721). You can do this using the "
Networking -> Ports" menu.

5. Make sure your classpath includes:
- all the class files of the sample apps
- <SDK>\examples\resources
- <SDK>\examples\lib
- <SDK>\examples\media
- <SDK>\lib
- <SDK>\lib\mappings

6. Run the sample application and call the IVR number from another phone. Follow the prompts.

Martin

UCID is a Universal Call ID and allows a call to be identified over several switches.

UUI is User to User Information (aka UserInfo or UserData). It allows a a user or application to add some information into the call. This information is not used by the switches but they do pass it on, in the expectation that the receiving end will know what to do with it.

If UUI has been added to the call, you can see it using LucentCallInfo.getUserToUserInfo().

So, say you have a Call object (eg. from an event), you can do something like:

if (call instanceof LucentCallInfo) {

    LucentCallInfo lucentCall = (LucentCallInfo) call;

    String UUIString = lucentCall.getUserToUserInfo().getString()'

}

Martin

I can't help you there, sorry. I think you have three options:
1. Write your own based on https://datatracker.ietf.org/doc/html/rfc3550 .
2. Purchase a stack from a vendor
3. Look for a free library online. RTP is a standard protocol and has been around for many years so I am sure there are several free libraries available.

Martin

So, it seems that:
1. The agents login in Auto-in mode so they become available immediately after a call
2. In specific cases, you do not want the Agent to be available for a new call

The way to achieve this is to use LucentV6Agent.setState(), DURING THE CALL, to change the agent's state to Aux Work (Work not Ready). BUT, you must set Pending to TRUE. That way, the agent will go in to the Aux Work state immediately it leaves the call and no more calls will be delivered to it.

When the call comes back to the agent, you can use setState() again to change the agent's state to Ready, with Pending set.

Martin

The RTP packets sent from Avaya Media Server/Gateway to your port are made up of Header and payload parts. Wireshark reads the packets over the wire and is able to extract the media in the payload.

I don't know why VLC can't handle the media as I do not know anything about how VLC works. It is worth noting that a media stream is more than just packets of data - the receiver must know things like the codec, encryption packet size ... It must also be able to handle network related issues, such as packets arriving late or out of order.

Avaya Media Stack is not of production quality and is only useful for some of the sample applications.

Firstly, the MakeCall fails because the calling party (52023) is already in a call (CallID 6844). This is due to 52023 being Retrieved back into the call just before the MakeCall.

Unfortunately, there is no way to tell from these traces why the call is retrieved. All we can say for sure that it is NOT due to actions performed by Nice or your application (via this AES).

The only possible causes I can think of are:
1. The agent presses a button on the phone/softphone to retrieve the call.
2. A DMCC application "presses" a button to retrieve the call
3. An application retrieves the call via a different AES.
4. Some feature of Communication Manager retrieves the call, though I can't think of any.

You could try running the SAT command "list trace station 52023" on CM. This gives information about the call as it progresses. However, it does tend to be very sparse so may not be very much help.

Martin

As I said, you can do a three-step transfer and use SA8481 at the MakeCall step.

Martin

AdamEurich wrote:Can you enter a bug with development for that for me please?

It is not a bug. DMCC is based on a standard which allows for UserData in an SST - hence it is in the xsd definitions upon which the SDK is based. TSAPI does not support UserData so it is ignored. You must always consult the TSAPI programmers guide when using Call Control features.

AdamEurich wrote:Is there a way in the phone switch setup that Avaya will automatically forward the ANI of the call when transferring?

I am not sure what you mean by this.

It does seem that the DMCC .Net SDK will accept UserData for SST. However, if you take a look at the TSAPI Programmers Guide ("TSAPI for Avaya Communication Manager Programmer's Reference"), you will see that SST does not take UserData (aka UserInfo). This is important because DMCC uses TSAPI for Call Control functions. It means that you cannot inject UserData into a call using SST.

I suggest you use a three-step transfer (Hold Call, Make Call, transfer Call). You will be able to inject UserData at the Make Call stage.

Martin

Some suggestions for you:

1. aes encryption is supported by Avaya Media Gateways but not by Avaya Media server (AMS). If you have an AMS, don't use aes encryption.
2. Make sure that you select srtp-aescm128-hmac32 or srtp-aescm128-hmac80 when registering the terminal. It is very easy to select the wrong value as there are a lot of very similar names.
3. On CM, run "list trace station <nnn>" and take the station off-hook. You will get some information which should help explain why the call is failing.

Martin