Hi Riza,

In order to retrieve user conversations from AMM, the user must be logged in. It doesn't require you to log in to other services though.

Ok, what isthe API call you are making to retrieve the value of the Display Name?
In SMGR the Display Name is configured via User Management interface.

Hi Rohit,

What API call you are using to retrieve the Display Name?
I need to understand whether you are trying to get a Display Name configured on System Manager(SMGR) or some directory data representing a Display Name.

Thanks,
Artem.

Does this resolve your issue?

Hi sercanoztorun,

Here is what our design team recommends -

"From the logs we see that the iOS Audio Unit wasn’t successfully initialized:
InitializeAudioUnit: Failed to initialize Audio Unit. Error: 561017449. Line: 638

This error (561017449) is defined in AVAudioSession.h:
AVAudioSessionErrorInsufficientPriority = '!pri', /* 0x21707269, 561017449 */
and is described as "The app was not allowed to set the audio category because another app (Phone, etc.) is controlling it."

Please make sure your app sets the Audio Session Category to “AVAudioSessionCategoryPlayAndRecord” prior to un-hold the VoIP session.

In general, the application should be always using this Audio Session Category when starting a VoIP session."

Thanks for your questions, the logs here is a good source of information, I will review them with the team and get back to you.

Another option would be to try this use case with Equinox Client and get logs from it.

Unfortunately, those are not debug level logs, so we cannot determine where the 2 calls are originated from. Did you have troubles enabling debug level logging?

Thanks for adding the logs, however, those are error level logs which don't tell us much. CSDK has setLogLevel method that allows to change the log level to debug. I wonder what happened to the first call. Was it accepted successfully and gracefully ended afterwards? A debug level log would clarify that.

Unfortunately, Session Manager trace doens't help much, what would really be of interest to us is Client SDK debug level logs from your application.

Hello,

Thank you for your question, would it be possible for you to share a complete debug level log trace with us?

Thanks,
Artem.

Hi jcvalsesia,

When user B gets an incoming call that they don't want to answer, there is a couple of options. They can either call Deny on the Call object which will result in sending a decline response back to the caller A, or they can call Ignore on the Call object which will just move the call into an ignored state locally and preserve the ability to answer the call, i.e. caller A will keep playing out ringbacks.

Once Deny is called by the user B, user A's call will get onDenied event and move to Ended state. Either of these events can be used to stop outgoing call ringbacks.

Hi Chris, thanks for your question. Can you explain the desired call flow in more details?

1. How is your TPIN authentication supposed to work?
2. What is the component hosting the IVR?
3. Are you interested in JavaScript or Native Breeze Client SDK?

With Client SDK you can make multiple calls as well as place them on hold and resume.

Hi all,

Can you please specify how your custom client implements data retrieval watcher callbacks?
We are going to simulate the same flow and see what might be wrong.

Thanks,
Artem.

Hi DincerGUNES,

Will you be able to enable Client SDK logging and reproduce the issue in order to get us a view on what is happening in your case?

Thanks,
Artem.