Dear Support,
I just got the CM version: R018x.01.0.890.0
Thanks,
Gabor Fenyvesi

Hi,
Thanks, we are doing Multiple Registrations call recording, and usually use the INDEPENDENT mode, but a new customer does not like it, because the CM assigns calls to the INDEPENDENTly registered devices (even if there is no MAIN registration), so they want us to use the DEPENDENT mode.
I realized that maybe my first question was not clear: so we receive this, and would like to know what it means:
3014: Registration Reject reason: resourceUnavailable Request rejected from switch with denial code= 18316, denial reason=
There is no test representation of denial code= 18316.
Regards,
Gabor

Thanks. Maybe a dummy question: what is the recommended way:
- first query the registration state and not try to register if there is no MAIN registration
- try to register without checking the MAIN registration, and ignore the failure if the error is "resourceUnavailable"
Regards,
Gabor

Dear Support,
When we try to register a device with DEPENDENT mode, and there is no MAIN registration on the device, then for a few devices we get this:
"3014: Registration Reject reason: resourceUnavailable Request rejected from switch with denial code= 18316, denial reason="
Our application considers this error as a normal situation: "Error Message: 3014: Registration Reject reason: resourceUnavailable Shared control denied because the DCP phone is out of service.", but we do not know what is "denial code= 18316". Can you explain what that means?
Thanks,
Gabor Fenyvesi

OK, thanks.
Gabor

Hi,
So they configure the correct password in our 3rd party application for a station and the application can register it, then they set an empty password in our 3rd party application and restart the application then it can register the extension successfully. If they never set the correct password in our 3rd party application for a station then the application cannot register it with an empty password.

I have got some additional information, they say that H.323 stations are always working properly:

We noticed that the passcode validation issue does not occur when an H.323 station is used. This applies to both the scenarios - new extensions and existing (already registered) extensions.
However, when an AST station is used, the passcode validation issue will occur for new extensions. The existing extensions will not be impacted by passcode change.
In AST, the user will login as SIP in ASM but getting feature from CM. So this extension type uses two protocols SIP and H.323. User will use the SIP station to make call and we believe the recorder will tap into the H.323 station in CM for recording.

Thanks,
Gabor Fenyvesi

They have upgraded to 8.1.1.0.2 and now the stations which were successfully registered previously can be registered without a password but the stations that were never registered still cannot be registered without a password.
Any hint?
Gabor

Dear Support,
We have a customer with AES 8.1.1 and we would like to register the stations (DMCC Multiple Registrations) without providing the station's password.
We understand what should be set up:
- The DeviceID contains the administered switch name associated with a valid switch connection to Communication Manager
- The switch connection to the Communication Manager is active and talking
- The SDB on the AE Server is enabled
- The user has "Unrestricted Access" in the SDB
- The extension’s class of restriction (COR) on the Communication Manager has:
- "Can Be Service Observed" set to "y"
- "Can Be a Service Observer" set to "y"
All above set up and they verified multiple times, also restarted services and AES, but we still receive this:
3000: Registration Reject reason: securityDenial Login Denied - Access Code invalid. diagnostic string= code= 63773

It used to work at other customers with older AES releases.

Do you have any idea what we should check?

Thanks and regards,
Gabor Fenyvesi

So we use Multiple Registrations, so registering on the phone, no separate extension is being used.
Thanks Martin, one additional note, that in the MediaStart event, when we do not receive the media, then the MediaStart event indicates that the media target is the AMS. If you still say that we should receive the media, then thanks, I will get back to the customer with this information and ask them to double(triple)-check the network.
Thanks again both you guys,
Gabor Fenyvesi

Dear Support,
If a call goes through the Avaya Media Server, can we record it using DMCC Multiple Registrations?
We have a customer where the same call scenario (the same caller and called) sometimes goes through the AMS, and in that case, we do not receive the media.
When the media goes through the G450 Media Gateway, then we get the media.
We receive the call events and the media events via DMCC so that part is working.
It can be a network problem, but they say the network is set up properly.
Thanks,
Gabor Fenyvesi

Hi,

We have exactly the same problem.

DMCC events just stop coming without any notification.
The same error in the AES logs:
TSAPI[7917]: ERROR:CRITICAL:G3PD:L 1622:C 2013:[LinkThread01]: Link 1 exceeded error threshold, close and reopen.
Then these errors come up:
asailink[2145]: ERROR:FYI:hold_message:No application for message -- ABORT crv(ffffff80, 03) on node signal33 TSAPI CM7/1
(no occasions of "No application for message" previously!)

Ahmed, did you find a solution?

So our customer should open a ticket with Avaya Client Services?

Regards,
Gabor

Hi,
Unfortunately, this happens even if we are calling the UnregisterTerminalRequest in a separated thread. It times out, and the DMCC library triggers a ServerConnectionDownEvent, and we do not receive important events for a while.
Do you have any best-practice on how to avoid this?
Thanks,
Gabor Fenyvesi

Thank you for the answer.
Let me ask one more thing: is it possible to get more information via JTAPI (instead of DMCC), or this "limitation" is at the ASAI level (I assume then there is no chance to get this data)?
Thanks
Gabor

Hi,
We ran into a similar scenario: we did a test where the Caller is monitored, the Called is not, and the Called parks the call. Then a 3rd phone (not monitored) picks it up, but the pick-up event is not sent to our DMCC application at all.
Is there any workaround that would let us get known the 3rd phone number?
Thanks,
Gabor Fenyvesi

That is great, thank you very much.