Hard to say for sure what the issue is. I couldn't reproduce it.

this._callbacks[t.getSurfaceId()] is initialized in whiteboardRenderer's addOnWhiteboardSurfaceAddedCallback with the whiteboard service is executed. That callback is initialized when whiteboardRenderer.init() is executed. So maybe your app is creating the surface before the whiteboardRenderer is initialized.

contentSharing.getOutgoingScreenSharingStream() is only for the outgoing screen sharing, ie. the presenters own view of what they are presenting.

The recipients of the screen sharing stream need to use the KonvaContentSharingRenderer to see the content sharing as described here https://www.devconnectprogram.com/site/global/products_resources/avaya_client_sdk/programming_docs/current/javascript/communication/guide/adding_support_for_web_collaboration.gsp

You should ignore anything starting with an underscore. That means its a private field, isn't intended for use by a client and may be changed in a future version without regards to backwards compatibility.

participant.isLocalUser() returns participant._localUser.
participant.isPresenter() returns participant.isPresenter. Presenter means you are allowed to present.

In general you should be using the participant functionality in the conference object. The participant list in the collaboration is of limited use and limited capabilities. I'm not sure if the duplicate is intended or not.

Theoretically the SDK could be used for a direct connection to a WCS without a UCCP connection to a Conference or a Call. In reality this isn't a supported deployment.

The id in the collaborations store is local. It doesn't reflect what is in the server.

I assume that collaboration.start() was executed successfully for both users.
Do you see logs for both user1 that it successfully connected? There should be a live_viewer POST request, followed by a WebSocket connection, followed by a live_session request and response.

In the live_session response you should see a meeting_id for both users. That meeting_id should be the same if they landed on the same WCS meeting. In the logs that id is removed but it should show up if you look at the websocket messages in the chrome dev tools.

As a sanity check you could join the same meeting from the Avaya Meetings portal and see if you can receive the screen sharing on that application.

You can change the language of the meeting invite in the user's virtual room configuration in the Avaya Meetings Management GUI.

I don't think there's a way to retrieve the meeting Id and PIN via the communications package.

I can't think of a reason off the top of my head. Please capture a new set of logs. Maybe that would help.

Thanks for the logs. They confirmed that the URL is coming correct from the server.

I went back and looked at the parsing for the URL and see that it is ignoring the protocol and using http or https based on the protocol of the page being rendered. This was an old workaround to avoid attempting http for an https site because the browser would not like it. I'm guessing you are serving your application from an http url. If you change it to https it should solve the issue. You need to use https anyways in order for webrtc to work.

Please only set the enabled field in the wcsConfiguration. As you noticed, the rest of the fields are purposely overridden when the url is parsed from the server.

ibogdan,

Avaya support has contacted me and is indicating that collaboration connection is working fine (with https) for the default portal client that comes with Avaya Meetings. That indicates it is likely a problem with the custom application. Can you please collect debug logs and attach them? https://www.devconnectprogram.com/site/global/products_resources/avaya_client_sdk/programming_docs/current/javascript/communication/tech/troubleshooting_and_debugging.gsp

Be sure to enable verbose logging in Chrome Dev Tools prior to capturing the logs. Thanks.

Yes.

Please take a look at the conference sample app. It shows how to join as a guest.

ACS in this case is the name for the contact service that is contained in both the AADS (Avaya Aura Device Services) and the Avaya Meetings portal. It's the backed for the SDK's Contact service.

UCCP in this case references the conference control protocol used to connect to Avaya Meetings and provides roster and chat services

The participantLaunchURL and swcLaunchURLforModerator are pointing to the Avaya Meetings portal. That is Avaya's default implementation of JavaScript CSDK communication's package similar to the custom application you are developing. You should be able to join the meeting using your application and dialing the meeting room number.

The meeting management package just provides scheduling. To join a meeting you need to use the communications package.

The JS version of the CSDK doesn't have an API to perform an adhoc conference with Avaya Meetings, but you can probably set one up manually.

- User A is on a call with User B and on hold with User C
- User A transfers User B to user A's virtual room number (callB.transfer())
- User A transfers User C to user A's virtual room number (callC.transfer()) You might need to unhold this call first.
- User creates a new call to their virtual room number.

This would require the meeting room not to be setup with a passcode otherwise the user would be prompted for a passcode which would be confusing.

Multiple calls are supported, but there's no API that allows the client to pick a line for a call

No, there is no network call history available.