Hello,

Our recording application connects softphone extensions via service observe to get the audio streams of monitored calls.
On one hand, we are listening to call control events to get informed about call flow on a monitored physical extension.
On the other hand, we are listening to media events to get informed when the softphone joins the call and starts streaming audio.

Usually the EstablishedEvent originated from the monitored physical extension and the MediaStartEvent originated from the softphone are arriving nearly at the same time.

Now we've seen some scenarios, where we've only got CallControlEvents, but no MediaControlEvents.
This behaviour happened in two independent installations.

Unfortunately, this issue is not really reproduceable. It may happen, that one call is signalized correctly and the next call does not sent any MediaControlEvent.

Both installations are running with AES V4.2.3.

Is there a known issue with missing MediaControlEvents or Service Observe malfunction?
Is there a way to check, if Service Observe is working correctly?

Regards,
Claus Suffel

Most likely you are running out of either TDM or MedPro resources. If resources for the party can not be acquired, then there will not be a MediaStart event; and without MediaStart there will not be a MediaStop.

Another possibility is that there is no matching codec available given the network regions involved in the call the ip-codec-set that imposes, and the supported codec by the party who is not getting a MediaStart.

Check the
list measurements blockage pn today-peak
list measurements ip dsp-resource summary today-peak
and
display events [denial]
for evidence of that.

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

it may not be available through the login you are using, but Communication Manager release 5.2 does support both commands. If you do not directly have access with the login you are using , you'll need to work with the Business Partner or Avaya Global Services (whomever installed and maintains the system) to gain access to that information.

THere is a specific column of data that shows blocked requests for resources, by hour of the day.

Depending on the specific resource blockage, the denial events log is also pegged in such situations.

There are no logs specific to SO, however if you involve Avaya Global Services or a BP maintenace team, they can typically enable internal logging and trace failure scenarios. This is very timeconsuming, and it is prudent to review the previously mentioned information for evidence of the system not being configured with enough resources to handle the call traffic load first.

just giving you ideas... I have seen the codec mismatch causing 'intermittent' problems because one network region was not properly configured wrt the recorders. Running out of hardware is the first thing I'd look for.

Have you opened a maintenance ticket for the problem? You should. The maintenance teams have access to a scripted document to look for out of resource problems on a system, but running through it is going to require more access permission than apparently you have to the system.

Recently we went through a similar problem. We solved the problem by changing the CM Network-region. By setting the Near End Establishes TCP Signaling Socket to "No" it forced CM to allocate the tcp port at registration and everything seemed to work.