Hello,

Our DMCC app uses SDK 5.2.2.69.
When trying to connect to an AES V4.2.3 our app failes with the following messages:

#########################################

Sep 6, 2010 3:47:44 PM com.avaya.mvap.svcproxy.prov.RemoteServiceProvider initServiceProviderImpl
INFO: CMAPI SERVER IP=192.168.93.207: CMAPI SERVER PORT=4721
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.SessionManagementServiceProxy startApplicationSession
INFO: AES release=4.2 protocol version=http://www.ecma-international.org/standards/ecma-323/csta/ed3/priv3
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaMarshaller setBackwardCompatibilityMap
INFO: map File=v52To42mapping.xml, includes xml maps for newer releases
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaMarshaller setBackwardCompatibilityMap
SEVERE: Failed to load XML mapping
java.lang.NullPointerException
   at org.exolab.castor.mapping.Mapping.loadMapping(Mapping.java:430)
   at com.avaya.mvcs.proxy.CstaMarshaller.setXMLMap(CstaMarshaller.java:116)
   at com.avaya.mvcs.proxy.CstaMarshaller.setBackwardCompatibilityMap(CstaMarshaller.java:99)
   at com.avaya.mvcs.proxy.CstaMarshallerNode.configure(CstaMarshallerNode.java:509)
   at com.avaya.mvcs.proxy.Pipeline.configure(Pipeline.java:173)
   at com.avaya.mvcs.proxy.ClientProxy.setPipelineVersion(ClientProxy.java:293)
   at com.avaya.mvcs.proxy.ClientProxy.sessionStart(ClientProxy.java:344)
   at com.avaya.mvcs.proxy.ClientProxy.<init>(ClientProxy.java:252)
   at com.avaya.mvap.svcproxy.prov.RemoteServiceProvider.initServiceProviderImpl(RemoteServiceProvider.java:197)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getCmapiServiceProvider(ServiceProviderBuilder.java:192)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderType(ServiceProviderBuilder.java:177)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderImpl(ServiceProviderBuilder.java:112)
   at com.avaya.cmapi.ServiceProvider.getCmapiServiceProvider(ServiceProvider.java:404)
   at com.avaya.cmapi.ServiceProvider.getServiceProvider(ServiceProvider.java:390)
   at com.asc.aes.connect.AESConnector.run(AESConnector.java:201)
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaUnmarshaller setBackwardCompatibilityMap
INFO: map File=v52To42mapping.xml, includes xml maps for newer releases
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaUnmarshaller setBackwardCompatibilityMap
SEVERE: Failed to load XML mapping in resolverMap
java.lang.NullPointerException
   at org.exolab.castor.mapping.Mapping.loadMapping(Mapping.java:430)
   at com.avaya.mvcs.proxy.CstaUnmarshaller.setXMLMap(CstaUnmarshaller.java:162)
   at com.avaya.mvcs.proxy.CstaUnmarshaller.setBackwardCompatibilityMap(CstaUnmarshaller.java:126)
   at com.avaya.mvcs.proxy.CstaUnmarshallerNode.configure(CstaUnmarshallerNode.java:292)
   at com.avaya.mvcs.proxy.Pipeline.configure(Pipeline.java:173)
   at com.avaya.mvcs.proxy.ClientProxy.setPipelineVersion(ClientProxy.java:293)
   at com.avaya.mvcs.proxy.ClientProxy.sessionStart(ClientProxy.java:344)
   at com.avaya.mvcs.proxy.ClientProxy.<init>(ClientProxy.java:252)
   at com.avaya.mvap.svcproxy.prov.RemoteServiceProvider.initServiceProviderImpl(RemoteServiceProvider.java:197)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getCmapiServiceProvider(ServiceProviderBuilder.java:192)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderType(ServiceProviderBuilder.java:177)
   at com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder.getServiceProviderImpl(ServiceProviderBuilder.java:112)
   at com.avaya.cmapi.ServiceProvider.getCmapiServiceProvider(ServiceProvider.java:404)
   at com.avaya.cmapi.ServiceProvider.getServiceProvider(ServiceProvider.java:390)
   at com.asc.aes.connect.AESConnector.run(AESConnector.java:201)
Sep 6, 2010 3:47:44 PM com.avaya.mvap.svcproxy.prov.ServiceProviderBuilder getCmapiServiceProvider
INFO: SERVICE PROVIDER = com.avaya.mvap.svcproxy.prov.RemoteServiceProvider
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaMarshaller marshal
WARNING: V52TO42_MAPPING does not have mapping
Sep 6, 2010 3:47:44 PM com.avaya.proxy.castor.CastorUnmarshaller unmarshal
WARNING: V52TO42_MAPPING has null resolverImpl in map {NO_MAPPING=org.exolab.castor.xml.util.ClassDescriptorResolverImpl@1444356}
Sep 6, 2010 3:47:44 PM com.avaya.proxy.castor.CastorUnmarshaller unmarshal
WARNING: Could not unmarshal: <?xml version="1.0" encoding="UTF-8"?>
<CallInformationEventsStartResponse xmlns="http://www.avaya.com/csta"><eventListenerId>80004</eventListenerId></CallInformationEventsStartResponse>
The class for the root element 'CallInformationEventsStartResponse' could not be found.{file: [not available]; line: 2; column: 71}
   at org.exolab.castor.xml.Unmarshaller.unmarshal(Unknown Source)
   at org.exolab.castor.xml.Unmarshaller.unmarshal(Unknown Source)
   at com.avaya.proxy.castor.CastorUnmarshaller.unmarshal(CastorUnmarshaller.java:179)
   at com.avaya.mvcs.proxy.CstaUnmarshallerNode$CstaUnmarshallerProcessorThread.run(CstaUnmarshallerNode.java:187)
   at com.avaya.common.util.concurrent.impl.RunnableWrapper.run(RunnableWrapper.java:53)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)
Caused by: org.xml.sax.SAXException: The class for the root element 'CallInformationEventsStartResponse' could not be found.
   at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown Source)
   at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
   at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   ... 8 more
Caused by: org.xml.sax.SAXException: The class for the root element 'CallInformationEventsStartResponse' could not be found.
   at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown Source)
   at org.exolab.castor.xml.UnmarshalHandler.startElement(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
   at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentScannerImpl$ContentDispatcher.scanRootElementHook(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
   at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
   at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
   at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
   at org.exolab.castor.xml.Unmarshaller.unmarshal(Unknown Source)
   at org.exolab.castor.xml.Unmarshaller.unmarshal(Unknown Source)
   at com.avaya.proxy.castor.CastorUnmarshaller.unmarshal(CastorUnmarshaller.java:179)
   at com.avaya.mvcs.proxy.CstaUnmarshallerNode$CstaUnmarshallerProcessorThread.run(CstaUnmarshallerNode.java:187)
   at com.avaya.common.util.concurrent.impl.RunnableWrapper.run(RunnableWrapper.java:53)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)
Sep 6, 2010 3:47:44 PM com.avaya.mvcs.proxy.CstaUnmarshallerNode$CstaUnmarshallerProcessorThread run
WARNING: Unexpected exception: java.lang.NullPointerException
java.lang.NullPointerException
   at com.avaya.mvcs.proxy.CstaUnmarshallerNode$CstaUnmarshallerProcessorThread.run(CstaUnmarshallerNode.java:196)
   at com.avaya.common.util.concurrent.impl.RunnableWrapper.run(RunnableWrapper.java:53)
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)

#########################################

It seems that the mappings file 'v52To42mapping.xml' cannot be loaded correctly even though it is available in the API directory '\lib\mappings'.

What might be the reason for this issue?
Is there any documentation that explains the functionality of the mapping mechanism and that specifies the installation requierements?

Regards,
Claus Suffel

Hello,

Our recording solution uses softphones to connect to a call via single step conference.

In some cases, trying to establish a SSC leads to a CallingDeviceOutOfServiceException. In consequence of that error, our software is not able to record the corresponding call.

Is there a way to check in advance, if a softphone is working correctly, or if it is in a 'out of service' state.

Re-registering the softphone after such an error situation usually leads to success.

Regards,
Claus Suffel

Hello,

Our application initiates a single step conference (silent mode) between an active call and a softphone controlled by the app.

We've found out that SSC cannot be established successfully, if for any internal extension participating in the call the attribute 'Data Restriction' is set to 'Y' (page no. 2 of station settings).

In the case this parameter is activated, initiating SSC always leads to an 'InvalidObjectTypeException'.

What is the reason for this behaviour?
Is it mandatory to set 'Data Restriction' to 'N' in order to use SSC?

Regards,
Claus Suffel

Hello,

Is there a way to reset WebLM's peak usage counters?

Restarting AES services, as mentioned in another forum thread, has no effect on our AES 5.2.1.

Regards,
Claus

Hi John,

The functionality is not clear enough for me yet.
So I have to ask some additional questions.

Suppose we have a IP hardphone and an associated wireless (DECT) phone (no mobile !).
Can both phones share the same extension number, or do they always have to use different extension numbers?

If they use a single, common number, is it possible to 'transfer' an incoming call from one extension to the other extension of the pair?
Is such a transfer reported via CallControlServices by sending events (e.g. TRANSFERRED), or is it handled as one single call without sending any event?

For testing, is it possible to configure such a 'shared number' environment with two standard IP desk phones?
Or is it mandatory to have a wireless phone?

In the second part of your statement, you've described a bridged appearance scenario.
In my understanding, both extensions do have unique extension numbers in such a case. Right?

Or is it also possible to configure 'bridged appearances' with a single shared number for both endsets?

Regards,
Claus

Hello,

Our call recording application uses DMCC CallControlServices and MediaServices to monitor physical extensions and to record audio data coming from softphones which are connected to a call via SSC.

This works fine with Desktop IP phones (96xx and 46xx series).

But how about wireless phones, like 3620 or 3640?
Are they working exactly like IP deskphones from the DMCC point of view? Or is there anything we must take care of?

Regards,
Claus

Hi John,

I've opened a support request (#08100) and attached the requested traces.

Please take over and inform us about the results of you analysis.

Regards,
Claus

Hello,

Is it possible to monitor a VDN with DMCC CallControlServices?

The idea would be to get CallControEvents from endpoints in the case a call is routed through the VDN.

In the case the endpoints are called directly, no events should be generated.

Regards,
Claus Suffel

Hello,

We have some questions concerning the RTP network load in a decentralized CM environment.

Let's assume that CM and AES are placed at a central location. Additionally we have several remote locations, each of them equipped with a media gateway that is connected to the CM via WAN.

At each remote location, trunks and endsets are connected locally to the particular media gateway.

The main communication traffic takes place at each remote location locally.

Now we want to connect DMCC applications in order to record RTP by connecting DMCC softphones via single step conference.
What would be the best place to attach these recorder(s)?
Is it the central location, next to CM and AES, or alternatively the remote location, where media gateways and endsets are residing?

How is the RTP stream routed in the case of a call between a endset at a remote location, the trunk at the same remote location, and a DMCC softphone monitoring this call?

Is RTP traffic limited to the remote locations' LAN in this case ,or are the packets routed through the WAN anyway?

Regards,
Claus Suffel

Hi John,

Unfortunately we are currently not able to update our AES to 4.2.2.

But we've already seen this issue in an external installation that is definitely running with AES 4.2.2.

Any ideas?

Is is possible that the CM version has an impact on the behaviour?

Regards,
Claus

Hi John,

Do you have any information about the status of this issue?
Would you be so kind to answer my questions below.

Thank you in advance.

Regards,
Claus

John,

Thank you very much for providing this information.

I hope we can modify our application in such a way, that it is able to handle the wrong call event information without running into critical states.

But of course, we need a fix for this issue asap.

How long will it need to release a patch that fixes this issue?

Is there a kind of 'official reference number' that we can forward to customers that may complain about this problem?

Regards,
Claus

Hi John,

First of all I'd like to wish you a happy new year!

Have you already been able to reproduce this issue?
If not, please can you give us an estimation for the time you need for analysis.

Regards,
Claus

Hello,

We've detected an odd behaviour with CallControl events in combination with external caller party.

Let's consider the following scenario:

1) External caller calls internal Ext_A
2) Ext_A initiates blind transfer to internal Ext_B
3) Ext_B picks up call and is connected to external caller

After doing this, we finally receive an ESTABLISHED event for Ext_B, containing following data:
calling device:   number of external caller
called device:      number of Ext_B

Now we perform the same steps, but with an external caller that has suppressed the submission of its own number.
In this case, the ESTABLISHED event looks like this:
calling device:   number of Ext_A
called device:      number of Ext_B

It seems that the calling device information is not correct. We would expect a tempory device id like 'Txxx#1' here.
Such a temporary id is delivered in all preceding CallControl events, but not in the final ESTABLISHED.

Now we can expand the scenario by performing additional steps:

4) Ext_B initiates normal transfer to internal Ext_C
5) Ext_C picks up call and is connected to Ext_B
6) Ext_B completes transfer
7) Ext_C is connected to external caller

Now we finally receive an TRANSFERRED event containing following data:
transferring device:      number of Ext_B
transferredTo device:      number of Ext_C
transferred connections:   external caller, ExtC

If external caller has suppressed submission of its number:
transferring device:      number of Ext_B
transferredTo device:      number of Ext_C
transferred connections:   Ext_A, ExtC

Displaying Ext_A in transferred extension list is not correct.
Temporary device id of external caller should be delivered instead.

Is this behaviour supposed to be like this, or are we faced to a bug here?

The issues described above seem to be related to DMCC only. Performing same steps with TSAPI Exerciser leads to correct events.

We are using following releases:
CM:      5.2
AES:   4.2.1

Ragards,
Claus Suffel

Hi John,

Unfortunately 'list measurements ip dsp-resource summary today-peak' is not availabe in our CM. We are running R5.2.

What kind of entry in the mentioned lists is referencing to an outage of TDM or MedPro resources?

Are there any logs inside CM or AES that are proving such an error?

Is there a log where we can trace the behaviour of a Service Observer?
Just to find out if the observer is not entering the call. Or if the observer works as expected, but only subsequent media events are missing.

As the MediaStart is not missing in every case, but only randomly on a specific extension., codec incompatibilities should not be the case here.

Ragards,
Claus