1. The DMCC XML SDK is just a collection of XML definitions. You can use it in any environment that is capable of opening a maintaining a socket with AES. So yes, you can use it on any Linux machine.

2. You can use DMCC to do anything that you can do with TSAPI.

Martin

I think it would be best if you were to open a technical support ticket for this query. Please include the XML sent to/from the dashboard and the output of the SAT command "list trace station <service observing station" . The list trace should cover the registration of the service observer DMCC terminals and the calls.

Martin

I performed the following test:

1. Use DMCC Dashboard to register two DMCC terminals in Independent & Client/FULL media mode (Instance 0 & 1), each with a different RTP/RTCP port.
2. Use one terminal to go off-hook & dial SO Listen Only access code + number of monitored station.
3. Make call to the monitored station from other station.
4. Use Wireshark to verify that both DMCC terminals receive media from both stations in the call.
5. Use the Dashboard to make SelectiveStreamRequest for each DMCC terminal. For Instance 0, the SELECTIVE_EXCLUDE list includes only the other station. For instance 1, the SELECTIVE_EXCLUDE list includes only the monitored station.
6. Use Wireshark to verify that instance 0 receives media only from the monitored station. Instance 1 receives media only from the other station.

So, working as expected.

Martin

I will do a quick test to see how an SO recorder interacts with Split Stream recording later today. But first, I want to try to clear up an misunderstanding that you seem to have.

For MAIN_STATION_ONLY and ALL_BUT_MAIN_STATION, the "MAIN" refers to the station of the RECORDER terminal. That is, if the DMCC terminal(s) used as a SSC/SO recorder are 1000 then:
- The MAIN_STATION_ONLY terminal will receive only media from 1000 - i.e. nothing
- The ALL_BUT_MAIN_STATION will receive media from everybody else - i.e. everybody in the call.

MAIN_STATION_ONLY and ALL_BUT_MAIN_STATION are only useful for Multiple Registration recorders. SSC and SO recorders must use a SelectiveStreamRequest with an SELECTIVE_EXCLUDE or SELECIVE_INCLUDE list.

That release does include a fix for the issue that John mentioned.

I have always thought of the Meta events as bookends to indicate the set of actual call events that have been triggered from a single state change/action. You may find it more useful to use these call events.

There are some legitimate cases where there is no calledAddress in a call. For example, if a monitored phone goes off-hook, an application may receive events but the call only contains one connection and there is no called number.

Martin

You would need support from the Avaya Experience Portal team for this. If you have a subscription, you should be able to open a OneCare ticket. Alternatively, there is an AXP forum at https://developers.avayacloud.com/onecloud-ccaas/discuss.

Martin

Sorry, I can't hep you there. Our remit is with APIs, not system design.

Martin

I read that to mean:
o If each AES has a separate IP Address, in different subnets, then you only get the basic features that I mentioned previously.
o If Each AES and their equivalent virtual IP Addresses are in the same subnet, you get extra benefits.

Please note that AES has 3 ethernet ports. Normally, in a lab we just use one port for everything. However for a production environment, you may prefer to use all three, each would be in a separate network. The Management port is used for administration, the private port is connected to CM and the public port is connected to application servers. This is why the document mentions virtual IP Addresses (plural) in places.

As far as I can tell from the DMCC PG, without virtual IP Addresses, GRHA gives very limited benefits. That is:
o Any configuration made to the active is reflected in the standby
o If the standby detects an outage of the active, it will bring itself into the active state
o There is only a need for one set of licenses.

If the application detects a lost connection to the active AES, it will need to start a new session with the (previously) standby AES and re-establish registrations and monitors.

I have attached an AES Admin guide and HA white paper which may give you more information than the programmers guide.

Martin

As of Aura 8.1 (ish), it is possible to use Custom Media Streams for this purpose. The appropriate programmers guide (Java, .Net or XML) has a section called "Custom Media Streams" which describes how this feature works. There is also a sample application in the Java SDK called selectivestream to give some pointers.

There is also an FAQ related to how Custom Media Streams affect the licenses required -
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/dmcc/index.gsp?tab=register&accordion=faq-30

Alternatively, the Selective Listen Hold feature can be used, though I think the Custom Media Streams is a better option .

Martin

So, you want an application that will automatically make an outgoing call and then inject DTMF into the call. Correct?

It is possible to do this using DMCC but I don't see any sample application that is a good match. Most of the sample apps are based on incoming calls or recording. The only sample that I can see makes an outgoing call is the Click2Call sample in the JAVA SDK. I think this allows a user to control an existing phone using a Java app. However, it's GUI based and integrates with LDAP so it may be easier for to to start from scratch.

The .Net SDK includes the DMCC Dashboard. This allows you to manually exercise DMCC functions via a GUI. It also has an Automated Testing feature. This records your actions and allows you to save, edit and play these actions. This would allow some level of automation.

Martin

According to the answer in the linked thread, the JTAPI Client will NOT automatically connect to an alternate link if the original goes down.

https://www.devconnectprogram.com/forums/posts/list/8914.page#p21688

The alternate link only comes into play when the client executed getProvider(). So, if the application detects that the link has gone down, it should execute getProvider() again and the client will connect to the first available link.

Martin

The latest version of JTAPI is jtapi-sdk-10.1.0.2.0.12 - presumably there were no changes needed to match AES 10.1.2 or 10.1.3.

You can download this from The Devconnect website at https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/releases/10_1_3/index.gsp#downloads

Martin

I have deleted the previous post as it seems to be spam. It was probably written by an AI to look plausible but the information in it was inaccurate.

Martin