Hi

I have a application to monitor Extensions by DMCC ThirdPartyCallController.StartMonitor().


When there are inboundCalls(DID or ACDSplit or VDN) from ISDN(E1) to a Extension, Application can not receive any Delivered or Established Event.
Strange things is that Application receive ClearConnection Event about InboudCalls of ISDN(E1), but the Call ID always is 5433 .

When there are outbound Calls from a Extension through ISDN(E1), Application can receive Delivered or Established Event.
And Calls of a Extension to a Extension , Application still can receive Delivered or Established Event.

Could anyone help me to solve this problem ?

Mimic what your application does using the DMCC dashboard. (this is part of teh .NET DMCC SDK).
Does it show the missing events?

Return to your application.
Are the events shown in the DMCC trace log (when set to FINEST)?


Let us know what you learn.

Hi JohnBiggs

I will try it when go back customer's office next time.

Hi JohnBiggs

Return to your application
Are the events shown in the DMCC trace log (when set to FINEST)?
--> I don't understand what is it mean, can you explain more detail ?, All I have is my application's log, not DMCC trace log. and what is 'FINEST' ?

Please review this FAQ for information relative to tracing from AE Services perspective.

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/dmcc/other.gsp#60

DMCC .net API Version 6.3.3
AESServer Version 7.x.x
Avaya CM Version , I don't know.

I got a XML Finest log in another customer side by doing a ISDN(E1) Inbound Call that are no any Delivered or Establish Event about this call in log.
When this call is cleared, I saw a droppedConnection Event in log, but the call identifier is '7721'.
Every Time I did ISDN(E1) Inbound Call, the droppedConnection Event's call identifier is always '7721' .

Some droppedConnection Event log is below.

......
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 634 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.SubscriptionManager FINER - EventSubscriber finished executing, took 18ms from time added to pendingEventSubscribeTasks queue to finish
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 635 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.SubscriptionManager FINER - Handling a class ch.ecma.csta.binding.ConnectionClearedEvent, session=session[session 344A1B41BFDD85A566F95570EC6B7E9F-10,DefaultTCPChannel Bound to SocketAddress: /10.1.237.141:4721 Connected to SocketAddress: /192.168.58.149:49837]
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 635 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.SubscriptionManager FINER - EventSubscriber executing, time in pendingEventSubscribeTasks queue=16ms
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 635 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINEST - [Begin] payload=class ch.ecma.csta.binding.ConnectionClearedEvent, id=9999, session=session[session 344A1B41BFDD85A566F95570EC6B7E9F-10,DefaultTCPChannel Bound to SocketAddress: /10.1.237.141:4721 Connected to SocketAddress: /192.168.58.149:49837]
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 635 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINEST - Marshaller: V70TO633_MAPPING, protocolVersion: http://www.ecma-international.org/standards/ecma-323/csta/ed3/priv9
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 636 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINER - Packaging a session[null] ch.ecma.csta.binding.ConnectionClearedEvent@157c48e
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 639 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINEST - Marshalled session[null] ch.ecma.csta.binding.ConnectionClearedEvent@157c48e to <?xml version="1.0" encoding="UTF-8"?>#012<ConnectionClearedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><monitorCrossRefID>156</monitorCrossRefID><droppedConnection><callID>7721</callID><deviceID typeOfNumber="other" mediaClass="notKnown" bitRate="constant">503:AES::0</deviceID></droppedConnection><releasingDevice><deviceIdentifier typeOfNumber="other" mediaClass...
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 639 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.ByteBufferToChannelNode FINER - Writing ByteBuffer=java.nio.HeapByteBuffer[pos=0 lim=969 cap=969], session=session[session 344A1B41BFDD85A566F95570EC6B7E9F-10,DefaultTCPChannel Bound to SocketAddress: /10.1.237.141:4721 Connected to SocketAddress: /192.168.58.149:49837]
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 640 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.ByteBufferToChannelNode FINEST - Wrote 969 of 969 bytes to the Channel, session=session[session 344A1B41BFDD85A566F95570EC6B7E9F-10,DefaultTCPChannel Bound to SocketAddress: /10.1.237.141:4721 Connected to SocketAddress: /192.168.58.149:49837]
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 640 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINEST - ClearableQueuedExecutor-1: Duration of marshalling = 4msec and null publishing = 1msecs, session[null] ch.ecma.csta.binding.ConnectionClearedEvent@157c48e
<135>Aug 19 04:47:00 AES70 DmccMain[26361] +00:00 2020 641 1 com.avaya.aes | :ClearableQueuedExecutor-1: com.avaya.mvcs.proxy.CstaMarshallerNode FINEST - [End]



So, I still have 2 problem to solve.
First one is no Delivered or Establish Event , and Second one is why call identifier is always the same ?

Could thjs problem are Avaya CM or AESServer wrong configuration ?

When I readed a document of 'Avaya Aura®? Application Enablement Services Overview and Specification.pdf' , I found Chapter 11 said that

QSIG Interactions
• ASAI: For ISDN trunks administered with Supplementary Service Protocol “b” (also referred
to as QSIG-enabled), ASAI is not able to track calls with supplementary UUI information.
ASAI does not support QSIG path replacement. If any of the QSIG optional parameters are
enabled on the Communication Manager QSIG Optional Features form, ASAI can not keep
track of the call.
Device, Media, and Call Control (DMCC) does not support the extensions of digits in length.
• CVLAN: Because the CVLAN service is implemented using ASAI, CVLAN support for this
feature is also incomplete.
• TSAPI: The TSAPI service does not properly handle certain call scenarios involving QSIG
trunks.
• JTAPI: Because JTAPI is an interface to TSAPI, JTAPI does not properly handle certain call
scenarios involving QSIG trunks.

Is it possible that I encountered was caused by this QSIG setup ?

I wouldn't leap to the problem being QSIG.

AESServer Version 7.x.x - find out which one.
Avaya CM Version , I don't know - find out which one.

You can also enable TSAPI tracing in AE Services and verify (by looking at the csta* logs) that the problem is originating at the AES or not.
https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/tsapi/index.gsp#10

Hi, JohnBiggs

AES Version: 7.0.1.0.4.15-0
CM Software Load: R017x.00.0.441.0

You are on a releases that had many problems, both in Communication Manager and in Application Enablement Services.
Please see this information:

https://support.avaya.com/ext/index?page=content&id=SOLN300267
https://downloads.avaya.com/css/P8/documents/101020687

Hi, JohnBiggs

The second webLink(https://downloads.avaya.com/css/P8/documents/101020687) on which I can download the pdf file.
But I have no right to use the first Weblink(https://support.avaya.com/ext/index?page=content&id=SOLN300267).

Could you help to download the file for me or another method to get it ?

Sorry the first link is to a page that can only be accessed via SSO and is marked "Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy" I just clicked into it, so I didn't think twice about providing you the link. Unless you have Avaya SSO credentials I am unable to share it with you.

The link provides mostly the same information that is in the PSN. It additionally has information related to best practices during an upgrade to install a patch for both stand alone and HA configurations, and some details on what the original issue was that triggered the creation of the patch, and resulting PSN. I don't think you need it to make your case that the system needs upgraded.

Hi, JohnBiggs

OK. Thanks a lot of you to provide the information.
I will persuade customer to try it in their site.