Unfortunately, I'm still not clear if you are using Breeze or not. If you creating these conferences using Java code that is running within a Breeze snap-in, then this forum is the proper place for this question to be answered. Otherwise, please use the normal channels you have available for support.

Please also post here what version of Breeze you are running by running the swversion command at the command line.

Thank you.

Hi,

I have a couple questions. Is this recurring conference something that you created through the Scheduled Conference portion of the Breeze API using the ScopiaRequest object? Also, what version of Scopia are you using and what version of the XML API document do you have?

Thanks.

--Rob Favero

You can use the record method of the MediaService to record a participant.

The standard approach that specifies language/country (for example, fr-FR) should be used in this context and should work with most TTS engines (like Nuance).

Please note that the method you refer to below became available in Breeze version 3.3.x, but it did not work with some character sets. Breeze 3.4 has been enhanced to support UTF-8.

The latest information you've posted makes it look as if the certificate being used has not yet reached its effective date. So I think you are having problems with configuration related to your certificates. Unfortunately, troubleshooting this kind of condition through forum posts is usually pretty difficult, so I would suggest that you work with your services representative to try to get this issue resolved, if you continue to have trouble.

Thanks.

Above you mention that the version of Breeze is 3.1.1. I'm suspecting that the version is actually 3.3.1.1, since the log entry you provided could only be generated on a 3.3 or newer system. Can you confirm the version number?

Also from the command line, please run the following command:

mscc

Then, please post the results here.

Thanks.

Hi,

This error can occur if your Avaya Aura Media Server has not been registered with your Domain Name Server. The Breeze node needs to be able to resolve the FQDN of your media server to its IP address. So can you check if your media server is registered in DNS?

Hi,

I'd like to look at logs to see if I can figure out what might be happening. Please run the following commands on the command line on Breeze:

ce dlogon
ce dlogw >logCapture

Then, while that last command is running, make a test call that reproduces the problem. Once you've encountered the error, you can do control-C at the command line. Then, please upload the logCapture file that has been created to this forum thread and someone will take a look at them.

Thanks.

--Rob

Hi,

I might have to figure out how to get someone with more expertise involved in answering your question, since my knowledge mostly involves the functionality available in the SchedConf API. However, let me explore this some more with you.

When you send your request, what XML response are you getting back? Also, for the conference ID (1293) have you included the value that you used for either the ServicePrefix or the ServiceTemplateId when you created the conference as the first part of the conference ID?

Thanks.

--Rob

Hi,

I'm not quite sure what might be going on. Are you using the Breeze SchedConf API to submit your requests to the Scopia XML API or are you making direct HTTP requests to the Scopia server? Are you seeing any error indications -- an exception thrown to your snap-in or an error in the asm logs or Scopia Connector logs or the Text* logs (the Text* logs are in /var/log/Avaya/sm)? If you are not seeing any error indications, could you please rerun the scenario with logging turned up to the FINEST level for the asm logs and the Scopia Connector logs and for your snap-in and then attach those logs? Also, please include the Text* log from that same timeframe.

Thanks.

--Rob

Hi, I'm a colleague of Joel's have some more relevant information that we were able to get from the Scopia team. I apologize for the delay in making this information available. Hopefully have been able to get somehow get past the issues here, but I'll post this information in case it might still be helpful for you and for future reference.

You wrote: ... ServicePrefix (71 for audio type I guess) / What all changes I need to do for video support?
---
The service prefix is related to whether or not a conference is audio-only or video. This is because the service prefix selects a meeting type, and the meeting type configuration can be configured to be audio-only.

You wrote: ... what setting/configuration changes I need to do in Avaya communicator & One-X to enable video calls?
---
Avaya Communicator & One-X soft phones both should be capable of connecting to a Scopia conference as video devices, as long as video is enabled on them. Then, I'm not sure how the lab you are using is configured, but the Session Manager configuration would also need to be set up with an entity link to the Scopia Management node so that the phones can call into the Scopia conference.

You wrote: So how do I get that meeting URL using Scopia XML API? / One thing I noticed that meeting URL is same which someone has configured in ScopiaConnector global properties ? so should I use that static meeting URL to join conference.
---
The creation of the meeting URL occurs within the Breeze API, which is why it cannot be retrieved when using the raw interface of the Breeze SchedConf API. As you wondered, you can use the static meeting URL from the ScopiaConnector global properties to join the conference.

You wrote: Java API has issue and my colleague had posted that issue on Breeze forum.
---
The issue with UNRECOGNIZED_SERVER_ERROR sounds similar to an issue where too many conferences are being scheduled in overlapping times where they all reserve conference ports and eventually attempt to "over-reserve". The Avaya Breeze SchedConf API always creates conferences with at least two reserved ports. I'm wondering if the Scopia setup in the lab does not have very many ports available, which then eventually leads to this error. The getReasonDescription() of the exception may provide additional detail to confirm this. I notice in the XML you posted above that no ports are getting reserved, so conferences created with that XML would not encounter the over-reserve condition.

Thanks.

--Rob

Hi, Daniel,

Joel is unavailable to answer questions on the forum today, so I'll be attempting to assist you with the situation you have described.

A couple other people on our team and I have attempted to reproduce the condition you have described. We did find a scenario that sounds similar to your situation.

Based on what I understand so far, I am assuming that you are doing calledParty.setPresentedDisplayName(name) in the callIntercepted method of your CallListener class. Is that correct? If so, could you instead add the method callAlerting(Participant alertingParty) to your CallListener class and invoke alertingParty.setPresentedDisplayName(name) from inside this method? If that does not work, could you then add the method callAnswered(Call call) to your CallListener and invoke call.getAnsweringParty().setPresentedDisplayName(name) in the new callAnswered method?

Let me know if one of these changes works for you, and then I can explain what is going on.