Hello,

According to chapter 4 of 'DMCC API Java Programmer's Guide' a switchover from a Main server to an ESS server will now be transparent to an application. Only in the case the automatic internal re-registration of a DMCC station fails on the ESS, the application will receive a TerminalUnregistredEvent.

But how about extensions registered for monitoring via MonitoringServices/CallControlListener?
Will these registrations also switch over to the ESS automatically. Are the monitors still operational after switchover or is there a need to re-register them manually to the ESS server?

Regards,
Claus Suffel

Hello,

Assuming that an external call is connected to an IVR, is it possible to monitor (and record) this part of the call via DMCC? Do the IVR ports behave like any other physical extension configured on the CM (identical call control event flow, ability to establish a SSC to the call)?

How about data (e.g. customer number) entered by the caller during his IVR session. Is this data accessible via DMCC? If so, is this data still available after the call is routed to an agent's extension?

Regards,
Claus Suffel

Your hint to restart the AES server did finally resolve this issue.
Many thanks!

Claus

Switch connection is configured and in operation.

We are sending the getCallInformation request immediately after getting a MediaStartEvent from AES.
This MediaStartEvent is a direct result of a SSC that is initiated by our application after getting an EstablishedEvent from a monitored extension.

This all happens within less than 300 ms.

When sending a CallInformationServices.getCallInformation request to an AES 4.2.4, we're receiving a CstaException.

In 'mvap-trace.log' we can find the following traces:

FINE: invokeID= 37 Routing request=session[session 01D6FBF93C0A0F15FFC7214557B904C5-72] com.avaya.csta.binding.GetCallInformation@14c02c6
2011-06-13 10.08.24,488 com.avaya.cmapi.intsvc.CallInfoHelperServicesImpl getExtension
INFO: getExtension 9401 on switch AEServer1
2011-06-13 10.08.24,488 com.avaya.cmapi.intsvc.CallInfoHelperServicesImpl getCallInformation
INFO: getCallInformation on extension: [AEServer1:9401]
2011-06-13 10.08.24,488 com.avaya.cs.callinfo.CallInfoImplA getCallInformation
FINE: Parameters: [AEServer1:9401]
2011-06-13 10.08.24,990 com.avaya.mvcs.callinfo.mci.MCI checkStatus
WARNING: MCI checkStatus session down
2011-06-13 10.08.24,991 com.avaya.cs.callinfo.DapiHandshake getDapiVersion
WARNING: Expected SWITCH_VERSION, but received
java.io.IOException: MCI ServerError error: internal logic error: serverID = AEServer1
   at com.avaya.cmapi.dapilinkmgr.DapiLinkManagerImpl.sendDapiData(DapiLinkManagerImpl.java:278)
   at com.avaya.cmapi.dapilinkmgr.DLMDirectWrapper.sendDapiData(DLMDirectWrapper.java:60)
   at com.avaya.callinfo.CallInfoMCITransport.sendMessage(CallInfoMCITransport.java:308)
   at com.avaya.callinfo.CallInfoMCITransport.syncQueryMessage(CallInfoMCITransport.java:319)
   at com.avaya.callinfo.CallInfoMCITransport.syncQueryProcess(CallInfoMCITransport.java:290)
   at com.avaya.cs.callinfo.DapiHandshake.getSwitchDapiVersion(DapiHandshake.java:196)
   at com.avaya.cs.callinfo.DapiHandshake.getDapiVersion(DapiHandshake.java:160)
   at com.avaya.cs.callinfo.CallInfoImplA.get_uid_from_ext(CallInfoImplA.java:230)
   at com.avaya.cs.callinfo.CallInfoImplA.getCallInformation(CallInfoImplA.java:545)
   at com.avaya.cmapi.intsvc.CallInfoHelperServicesImpl.getCallInformation(CallInfoHelperServicesImpl.java:133)
   at com.avaya.cmapi.extsvc.CallInformationServicesImpl.getCallInformation(CallInformationServicesImpl.java:108)
   at sun.reflect.GeneratedMethodAccessor33.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at com.avaya.platform.broker.impl.AsyncServiceMethodImpl.invoke(AsyncServiceMethodImpl.java:164)
   at com.avaya.workflow.impl.RouterImpl.routeRequest(RouterImpl.java:97)
   at com.avaya.mvcs.proxy.CstaRouter.routeRequest(CstaRouter.java:173)
   at com.avaya.mvcs.proxy.CstaRouterService.routeRequest(CstaRouterService.java:141)
   at com.avaya.mvcs.proxy.CstaRouterNode.processPacket(CstaRouterNode.java:330)
   at com.avaya.mvcs.proxy.AbstractPipelineNode.process(AbstractPipelineNode.java:130)
   at com.avaya.mvcs.proxy.Pipeline$PipelineSubscriber.inform(Pipeline.java:427)
   at com.avaya.common.eventservice.UnfilteredSubscription.notify(UnfilteredSubscription.java:70)
   at com.avaya.common.multicaster.Multicaster.notify(Multicaster.java:386)
   at com.avaya.common.channel.Channel.publish(Channel.java:115)
   at com.avaya.common.eventservice.EventService.publish(EventService.java:123)
   at com.avaya.common.eventservice.EventServiceManager.publish(EventServiceManager.java:156)
   at com.avaya.common.eventservice.Publisher.publish(Publisher.java:110)
   at com.avaya.mvcs.proxy.CstaUnmarshallerNode$CstaUnmarshallerProcessorThread.run(CstaUnmarshallerNode.java:253)
   at com.avaya.common.util.concurrent.impl.RunnableWrapper.run(RunnableWrapper.java:47)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
   at java.lang.Thread.run(Thread.java:595)

What is the exact meaning and the potential cause of the MCI ServerError?
How can we prevent this error?

We are using DMCC Java API 5.2.2.69.

Regards,
Claus

Hi John,

Thanks for your quick response.

As requested, I've opened a support request (#10013) containing the same question as below.

Maybe you can take this over and add your comments there.

Regards,
Claus

Is it possible to monitor and record Avaya one-X Attendant Console via DMCC?

We have a recording application that registers softphones and monitors physical extensions. In the case of a detected call, the app establishes a Single step conference to an available softphone. RTP stream is then sent from the connected softphone to our application.

Now we want to observe a one-X Attendant Console in a similar way.

Thanks,
Claus Suffel

Hi John

While doing some station tracing I finally found out that the cellular's reported number didn't match the number configured for incoming EC500 calls.

After adapting this setting, incoming calls from the cellular extension are now correctly announced as calls coming from the associated office extension.
This works fine for calls coming from the cellular and going to an internal party on the same switch.

Now, there's only one question remaining:

Is it also possible to initiate a call at the cellular ext that is going to an EXTERNAL party and behaves exactly like a call originating at the associated office ext?
Especially we need to retrieve the RTP of such calls for recording purposes.

Regards,
Claus

Hello John

I've now managed to configure EC500 on our lab system.
Works fine for incoming calls.

As far as I can see now, the behaviour is exactly the same, independent of the device where the call is finally picked up (cellular or office ext).
RTP is provided as usual and the call control events seem to be identical to a call that goes to an extension without EC500 enabled.

What I didn't manage so far is testing the opposite call direction, means calls that are initiated by the cellular extension and routed through EC500 to an internal or external partner.
I would expect that such a call behaves exactly like a call initiated by the associated office extension. The called partner should see only the office phone number as calling party in this case.

I've browsed through several manuals, but it is still not clear to me how to set up and use EC500 for outbound calls.

Any help would be appreciated here.

Regards,
Claus

Thank you very much for your efforts.
We're looking forward to hear about your testing results.

Concerning the license topic, Andy already told me, that there is no need for a license update on CM 6 (see ticket #9707).
The features can be enabled by changing some configuration parameters.

Hi John,

We've already discussed a similar question in a support request (#09685). You may take over this request in the case there is a need for further testing efforts.

The guy who has answered this thread told us, that the media stream will NOT be delivered in the case an EC500 extension is participating in a call.

Please can you clarify this issue and give us a reliable information about what's happening with audio/RTP in the case the mobile extension picks up the call.

At the moment we are very confused because we've got two contradictory statements from Avaya.

Thanks.

Regards,
Claus

Our DMCC recording application connects softphone extensions via SSC to get the RTP packets of the call at a monitored extension.

What happens in the case there is an EC500 mobile extension attached to the standard CM extension?

Is it possible to record calls that are picked up at the mobile exactly in the same way, as if the calls were picked up at the main extension?

Is the flow of CallControl and Media events identical to a call that is picked up at the main extension?

Which extension numbers are appearing in the events?

Regards,
Claus

We are trying to support the following scenario with our DMCC recording application:

Two CMs that are running in parallel, load-balanced mode (50% of the calls are handled by CM_1 and 50% are handled by CM_2).

A single AES that is configured with two Switch connections/CLANs (Conn_1 for CM_1 and Conn_2 for CM_2).

Our application has to set up a CallControlListener for each monitored extension. Additionally we have to register a pool of softphones that are used for SSCs to the calls that need to be recorded.

How can we ensure that the application works in such a distributed environment?

In detail, we have the following questions:
1)
To register a CallControlListener for a specific extension, a ThirdPartyDeviceId is needed. To get this ID via a GetThirdPartyDeviceId request, it is mandatory to fill in a SwitchName parameter.

Which SwitchName must be entered in the scenario described above?

If we enter the name of CM_1, do we get CallControlEvents even if a call is handled by the opposite switch?

2)
If we receive call state events for an ongoing call on a monitored extension, is it possible to establish a SSC from a softphone registered on CM_1 to this call, even if the call is actually handled by CM_2?

3)
Is there anything else we have to be aware of in such a
scenario?

Ragards,
Claus Suffel

Hi Patrick,

There really has been an issue with the build path of our app.
After fixing this, the mapping file is loading correctly.

Thank you very much for your support.

Regards,
Claus

Hello,
Our call recording application basically uses DMCC Java API to connect a softphone enabled extension to an ongoing call on a monitored physical device via SSC.

Would this kind of operation also be possible, if we have a single AES server that is connected to multiple Communication Managers?

We would like to monitor extensions on all of those CM's in parallel.
Is there a need, that the softphones used for SSC must always reside on the same CM as the device that should be recorded?
Or is it also possible to connect a softphone configured on one CM to a call that is assigned to another CM?

Are there any requirements or restrictions we must be aware of?

Regards,
Claus Suffel