Hello folks,

I have found a condition where the UCID of a call changes. This happens after I merge two calls with the CallControlCall::conference function.

If I have callA(ucid=111, state=ACTIVE) and callB(ucid=222, state=ACTIVE) and execute callA.conference(callB) then I end up with callA(ucid=222, state=ACTIVE) and callB(ucid=222,state=INVALID). So the UCID of callA changed to the UCID of callB.

I expected that the UCID of calls stays the same no matter what operations are performed.

This causes some problems for me, because I rely on the UCID when processing call events.
For example after the conference operation I receive the multiCallMetaDataMergeEnded event which looks like this: MetaEvent(newCallI=(ucid=222), oldCalls=[(ucid=222),(ucid=222)]).
With this behaviour I never get an event again that contains information about a call with UCID 111. I only get evets for a call with UCID 222 when they are really events for the other call. This makes it impossible for me to interpret the events correctly.


Do you know if this UCID behaviour is intended? Is this a bug or is it dependent on a setting somewhere else in the AVAYA system?

Best regards,
Philipp

The handling of CallIDs and UCIDs during conferences and transfers is quite complex. There is an FAQ on this subject which should help you:

https://www.devconnectprogram.com/site/global/products_resources/avaya_aura_application_enablement_services/support/faq/index.gsp#1260

Martin

Thanks Martin for the link to the FAQ, that actually explained a lot.

I checked if I could get the old UCID from the orginalCallInfo object. But after the conference operation the originalCallInfo is not set. And when checking a call from the multiCallMetaMergeEnded event the originalCallInfo is set but contains the UCID "00000000000000000000".

At the moment I assume in a correct Avaya setup the originalCallInfo contains the previous UCID that I need.
So this seems to be configuration issue outside of JTAPI.
Do you think this assumption is correct or is there anything I missed?

Thanks and regards,
Philipp

Hi Philipp,

Without testing this, I cannot be sure exactly what should go where but, assuming there should be UCID in the OCI, I suggest you:

1. Check that there is UCID in other events. I think there are a couple of settings on Communication Manager which could control whether or not UCID is generated or sent to AE Services. If you are getting UCID in any events, then these settings must be OK. If not you will need to fix them.

2. I have only ever used Meta events to group signalling events together - never for actual data - so I am not sure if the Meta event ever includes UCID. Check the events that are generated by the conference to see if they include UCID in the OCI.

3. Check the TSAPI Link status using the AE Service web interface and make sure the protocol version number is as high as possible. It could be that the interface between CM & AES is using an older protocol version which does not include UCID when the conference happens.

Martin