I'me trying to monitor calls not answered using DMCC failed events but i'm unable to receive the event when calls over PRI E1 trunks not answered, only calls on SIP trunks throw the event response.

I've tried using multiple AES versions from 5.2 to 7.1.1 with all protocol versions available.

What are you doing in your application to monitor for no-answer events?
Specifically what do you consider a no-answer event to be?
What event are you seeing in the SIP call flow?
Are these inbound or outbound calls you are monitoring?
What device in the call flow are you monitoring?

What are you doing in your application to monitor for no-answer events?
ThirdPartyCallController.ThirdPartyCallControlEvents CallControlEvents;
CallControlEvents = new ThirdPartyCallController.ThirdPartyCallControlEvents(false);
CallControlEvents.FailedEvent = true;
InvokeId = serviceProvider.getThirdPartyCallController.StartMonitor(DeviceId, CallControlEvents, null);

serviceProvider.getThirdPartyCallController.OnFailedEvent += new FailedEventHandler(getThirdPartyCallController_OnFailedEvent);

void getThirdPartyCallController_OnFailedEvent(object sender, ThirdPartyCallController.FailedEventArgs e)
{
MessageBox.Show("" + e.getEventCause + "");
}
Specifically what do you consider a no-answer event to be?
Outgoing call over the PRI trunk to my cell phone with no answer

What event are you seeing in the SIP call flow?
CALLNOTANSWERED

Are these inbound or outbound calls you are monitoring?
Outbound calls

What device in the call flow are you monitoring?
H.323 9600 series IP phone with CM 7.0 and AES 5 or 7.0 or 7.1.2

thanks for the clarifications on how you are looking for failed events. As you may surmise, a failed event occurs when the network service provider returns certain cause codes back to the PBX. Historically once a call was launched into the network, the destination entity was often charged with providing any tones and feedback. In other words, a no answer condition did not necessarily clear the call back to the originating PBX.

So in the cases where you are not seeing the call failed event, how are you assuring yourself that the call is clearing back to the originating PBX (Communication Manager)? My suggestion would be to use the SAT and do a "list trace tac XXX" on the outbound trunk group.

If there is a disconnect occurring, then I would alter the monitor (or use the DMCC Dashboard) and execute the same call scenario and see what type of clearing indication is being sent, and adjust what the code is monitoring for, it may be that the indication that the PBX is receiving from the network on the ISDN facilities is not indicating the reason that the call is being cleared 'clearly.'

I tried this using the dashboard where the monitored station is 2231 kindly find below the XML messages from the dashboard

-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<LampModeEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>430</monitorCrossRefID>
<device>
<deviceIdentifier typeOfNumber="other" mediaClass="voice" bitRate="constant">2231:EFG:10.255.252.40:0</deviceIdentifier>
</device>
<lamp>262</lamp>
<lampMode>2</lampMode>
<lampBrightness>unspecified</lampBrightness>
<lampColor>3</lampColor>
</LampModeEvent>
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<DisplayUpdatedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>430</monitorCrossRefID>
<device>
<deviceIdentifier typeOfNumber="other" mediaClass="voice" bitRate="constant">2231:EFG:10.255.252.40:0</deviceIdentifier>
</device>
<logicalRows>1</logicalRows>
<logicalColumns>48</logicalColumns>
<contentsOfDisplay>
</contentsOfDisplay>
</DisplayUpdatedEvent>
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<DisplayUpdatedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>430</monitorCrossRefID>
<device>
<deviceIdentifier typeOfNumber="other" mediaClass="voice" bitRate="constant">2231:EFG:10.255.252.40:0</deviceIdentifier>
</device>
<logicalRows>1</logicalRows>
<logicalColumns>48</logicalColumns>
<contentsOfDisplay>a=901095939008 </contentsOfDisplay>
</DisplayUpdatedEvent>
-----------------------
Incoming XML 9999
<?xml version="1.0" encoding="UTF-8"?>
<NetworkReachedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>432</monitorCrossRefID>
<outboundConnection>
<callID>6553</callID>
<deviceID typeOfNumber="dynamic" mediaClass="notKnown" bitRate="constant">T6553#2:EFG::0</deviceID>
</outboundConnection>
<networkInterfaceUsed>
<notKnown />
</networkInterfaceUsed>
<callingDevice>
<notKnown />
</callingDevice>
<calledDevice>
<deviceIdentifier typeOfNumber="implicitPublic" mediaClass="notKnown" bitRate="constant">1095939008:EFG::0</deviceIdentifier>
</calledDevice>
<lastRedirectionDevice>
<notKnown />
</lastRedirectionDevice>
<localConnectionInfo>connected</localConnectionInfo>
<cause>normal</cause>
<extensions>
<privateData>
<private>
<NetworkReachedEventPrivateData xmlns:ns1="http://www.avaya.com/csta" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="NetworkReachedEventPrivateData">
<progressLocation>user</progressLocation>
<progressDescription>inband</progressDescription>
</NetworkReachedEventPrivateData>
</private>
</privateData>
</extensions>
</NetworkReachedEvent>



Received Lamp Update Event for 2231:EFG:10.255.252.40:0
Monitor Id: 430 lamp Id: 262 Color: Green Mode: Off
Display Update Event: 2231:EFG:10.255.252.40:0Monitor ID: 430 ""
Display Update Event: 2231:EFG:10.255.252.40:0Monitor ID: 430 "a=901095939008 "
Network Reached Event: 432
Called Device:
Cause: normal
Local Connection Info: connected
Network Interface Used:
Progress Description: Undefined
Progress Location: User
Outbound Connection Id:
Call Id: 6553
Device Id: T6553#2:EFG::0

-------- Device History Start-------------------------
Device History List Items: Size=0

-------- Device History End

<NetworkReachedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">

indicates that the call transitioned from ISDN to non-ISDN (analog) trunking facilities, and thus all further call progress indications will be in band.

I'm going to us this event for not answered calls
void getThirdPartyCallController_OnNetworkReachedEvent(object sender, ThirdPartyCallController.NetworkReachedEventArgs e)
{
if (e.getProgDescription.ToString().Equals("Undefined") & e.getLocalConnectionInfo.Equals("connected"))
{
}
}

and this one if Mobile not available

private void getThirdPartyCallController_OnOriginatedEvent(object sender, ThirdPartyCallController.OriginatedEventArgs e)
{
if(e.getEventCause.ToString().Equals("newCall") & e.getLocalConnectionInfo.Equals("initiated"))
{
}
}

The Network Reached event does not indicate whether or not the call is (or will be) answered. It indicates that you will not be able to get any more information about the call until it ends. So you will not have any way of knowing if it was answered. You will not even be able to tell if it was diverted to some other phone or voicemail.

Martin

Correct, but by testing this Network Reached event only triggers when the call is not answered so i will assume that if this event occurred it means that the call is not answered.

I do not think you can rely on that being the case in all circumstances.

Do you think If using TSAPI API i'll have the same issue or i can get better results?

JTAPI events are triggered from TSAPI events. Using TSAPI will not make any difference.

Martin

Sad to hear this but anyway thanks a lot for your support guys.

"Correct, but by testing this Network Reached event only triggers when the call is not answered so i will assume that if this event occurred it means that the call is not answered."

My guess is that in the environment you are testing in the network service provider is switching the call to another facility (non-digital) in the no answer case (probably to play an announcement), and then clearing the call. Given the network provided network reached (a terminal progress indication), their implementation cannot /does not provide a no answer indication in the clearing messages (or perhaps it isn't allowed in that call flow). I agree with Martin that RELYING on Network Reached event to indicate no answer is not a correct implementation as the message only means that further call progress indications are in band. The call can be answered by someone or sent to a tone or announcement by the network. Your application can not discern the difference once this message is received. You might make some assumptions based on the timing of this event and subsequent clearing of the call (e.g. know the length of the no answer announcement) but that would only be applicable on one particular network, as different service providers may well use different announcements (different languages for example), and the outbound call could reach any random service provider's announcement depending on the dialed number.

Sorry for the news, but legacy network devices are not as well behaved as the current digital network.