Hello,

Our application uses CallControlEvents to track call activity.
In the case of a Transfer or a Conference Call, we're using the ConnectionList parameter to generate the participant list of the resulting call.

In the case of Bridged Appearance, we've now detected that the information delivered with ConferencedEvents or TransferredEvents is not really suitable.

The connection list always contains ALL bridged devices, and not only the devices that are really participating in the call.

Example:
A has bridged appearance on B & C
B has bridged appearance on A & C
C has bridged appearance on A & B

If A is called, and the call is transferred, the ConnectionList of the TransferredEvent contains A, B and C, even if B & C are no active members of the call.

Is there a way to find out, which extensions are really participating in the call.

Regards,
Claus Suffel

Hi John

Thank you very much for your efforts in clearing up this topic.
We will discuss the described possibilities internally.

Please keep us informed in the case you will have more information about Avaya's future plans to enhance F/T's capabilities in the desired direction.

Please can you just add some additional information regarding our last question about the handling of private data with F/T.

Best regards
Claus

Hello,

We are currently investigating in how we can adapt our current DMCC recording application to Avaya's ACE platform.

Currenty, our recording app receives RTP streams through softphones which are connected to the recorded calls via SSC.

After browsing through the ACE FT developer docs, we unfortunately have not found any direct equivalent to redirecting RTP streams.

The only recording method described in the docs is the use of MediaService to store the audio to a file on the server.
Since we need a real time access to the audio data of a call, this approach does not fit our requirements.

A potential idea to retrieve a calls audio data is to register a SIP extension and to establish a conference from this 'softphone' to the call we want to record.

Unfortunately, it seems that conferencing to a third party is not sopported with sequenced apps. Is that correct?

Might it be possible to use a sequenced app to redirect the call to an endpoint app which finally establishes a conference between caller, callee and a recorder softphone?

Are there perhaps other methods available to fulfill our requirements?

Another topic that is not explained in the developer docs is the availability of additional call information (private data).
How can this data (agent id, VDN, universal call id, etc.) be retrieved with means of ACE FT?

Regards,
Claus Suffel

Hi John,

Thanks for this great explanation.

But now I have to come back to my initial question:

I've asked, if it is possible to add a DMCC softphone to a call between two 96xx phones and to get a G722 audio stream out of it.
This scenario would definitely be a 3 party call.

Considering your statement, that CM hardware cannot conference G722 audio at all, it would not be really helpful, if DMCC API will support G722 in the future.

Regards,
Claus

Just one more question:

For a plain softphone instance which is only registered via the application, it is clear that this softphone does not support G722.

But what happens in the case of a softphone that is registered against a (softphone enabled) hardware 96xx station.

The 96xx itself is able to run in G722 mode, but the softphone instance is not.
Does the hardware phone automatically fall back to another codec as soon the softphone is registered against the same extension?

OK, thanks for your investigations.

Please keep us informed in the case you'll get more information about the scheduling of your change request.

Regards,
Claus

Hi John,

Are you really sure that the current XML API already supports G722 codec?

I've checked the XML API for rel. 6.1. There is also no G722 option mentioned within documentation and XSDs. The programmer's guide contains just a list of available codecs similar to Java API.

Same thing with 'AES Admin and Maintenance Guide'. This manual also demands to set codec to G711A/MU or G729 for DMCC devices (see p. 36).

If G722 will be supported by Java API in the near future, please can you give us an estimation when this feature will be available.

Regards,
Claus

How can I set codec to G722 with DMCC Java API?

Only the following options are available:
G711A
G711U
G729
G729A
G723

Hello,

We have 96xx phones configured for G.722 as primary codec and G.711MU as secondary codec.

When trying to conference a DMCC softphone into a call that is established between two of these 96xx phones, the codec always switches to G.711MU..

Is there any chance to get a G.722 encoded audio stream via DMCC?

Regards,
Claus Suffel

Hello,

When picking up a parked external call at another extension, the EstablishedEvent contains incorrect device information.

Call scenario:
1) External party 0123456 calls internal party 1011
2) 1011 answers
3) 1011 parks the call
4) ext 1015 picks up the parked call

Now 1015 delivers an EstablishedEvent containing the following device ids:

answeringDevice: 1015
callingDevice: 1011 (should be 0123456)
calledDevice: 1011
lastRedirectionDevice 1011

In the case of an internal call, calling/calledDevice information is correct at pickup.

Is this a known issue?

We're using:
CM: R016x.00.1.510.1
AES: r6-1-1-30-0
DMCC SDK: 6.1.1.90

Regards,
Claus Suffel

Hello John,

First of all, Thanks for helping us even during your vacation.

I've opened ticket OPENTECH12459 for this issue.
AES log files are attached to the ticket.

I'd like to wish you a pleasant vacation and, of course, a happy New Year!

Regards,
Claus

Hello John,

We are working with:

AES: r6-1-1-30-0
CM: R016x.00.1.510.1
DMCC: 6.1.1.90

Softphones are registered in client media mode.

Checking the dmcc-trace.log.x also gives no further hints.
We can see the RedirectMediaRequest (with changed destination port) coming in, but the packets are still going to the old port.
This can be verified with Wireshark.

Regards,
Claus

Hello,

We are trying to redirect the media stream of a previously registered device to a new target address (according to the description in DMCC JAVA API docs):

RedirectMediaRequest redirReq = new RedirectMediaRequest();

IPAddress localRtpAddress = new IPAddress();
localRtpAddress.setAddress("192.168.169.115");
localRtpAddress.setPort(new Integer(20000));
                  
IPAddress localRtcpAddress = new IPAddress();
localRtcpAddress.setAddress("192.168.169.115");
localRtcpAddress.setPort(new Integer(20001));
                  
MediaInfo localMediaInfo = new MediaInfo();
localMediaInfo.setRtpAddress(localRtpAddress);
localMediaInfo.setRtcpAddress(localRtcpAddress);

redirReq.setDevice(softphone.getDeviceID());
redirReq.setLocalMediaInfo(localMediaInfo);
redirReq.setUsePreviousValues(new Boolean(true));
                        
RedirectMediaResponse response = regSvcs.redirectMedia(redirReq);


The RedirectMediaRequest with new address/port settings is sent via RegistrationServices.redirectMedia().
RedirectMediaResponse is coming back as expected, but the media is still sent to the 'old' destination.

We've tried to redirect the media for an active device with an ongoing call, and also for an idle device. Same result in both cases.

Browsing through g3trace file also gives no clues for resolving this issue.

Is there a general issue with media redirection?
Do you have additional hints how to solve this issue.

Regards,
Claus SUffel

Hi John,

Are you sure that attaching a CallControlListener (by using Java API's MonitoringServices.addCallControlListener) to a CallMaster V device will really work?

I'm asking because a while ago, we had a similar issue with an one-X Attendant console.

We did not manage to monitor such a device. Trying to monitor an one-X attendant always ended up in an 'InvalidDeviceException'.

What is the difference between a CallMaster V terminal and an one-X Attendant from the DMCC point of view?

Please can you also explain why the CallMaster V terminal is classified as 'not spekerphone equipped'.
As far as I know, it is a real hardware device that is used in conjuction with an attached headset.

Regards,
Claus

Hello,

Are CallMaster V devices supported by DMCC?

We need to monitor those devices via CallControlServices.
In the case of a call, we want to establish a SSC to a softphone in order to get the rtp stream of the CallMaster V device for voice recording.

Regards,
Claus Suffel