The scenario is the following:
User 1 joins his Meetme conference room and getCollaborationForCall is called to get the Collaboration instance that is then started.
User 1 invites User 2 to his Meetme conference.
User 1 has added the callback contentSharing.addOnContentSharingStartedCallback
User 2 starts screen sharing:
collaboration.getContentSharing() is used to get the content sharing instance, the content sharing renderer is initialized and contentSharing.startScreenSharing() is used to start the screen sharing.
We use contentSharing.getOutgoingScreenSharingStream() and we can visualize the screen share as the presenter (User 2).
contentSharing.addOnContentSharingStartedCallback of User 1 is not triggered.
How can User 1 access the screen sharing stream of User 2 ?

From my debugging while I was testing the scenario above, after having User 2 connected to the Meetme conference of User 1, I have checked the _collaborationsStore of both users.
Even though the users are in the same call/conference, inside the _collaborationsStore:
User 1: _callId: "d8d17f88-3a64-483a-bc5c-6cbae512b6ab" and _collaborationId: "n8GCXJPAui"
User 2: _callId: "afb5474f-6cfb-4a28-8b00-09d64d09b2c8" and _collaborationId: "u8OhjuLbpb"

From the documentation of getCollaborationForCall:

Gets or creates a new collaboration session for the given Call id.
Returns the collaboration if the call already has the collaboration.
Otherwise create the new collaboration for specified call.

I suppose both users should have the same collaboration inside the _collaborationsStore ?

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.

For both users I can see:

Request URL: https://amms1<project_name>.aps.gl.avaya.com/viewer/rest/live_viewer/

Request Method: POST

Status Code: 200 OK

Followed by a:

Request URL: wss://amms1<project_name>.aps.gl.avaya.com/wcsws/WebSocket

Request Method: GET

Status Code: 101 Switching Protocols

But there is nothing related to live_session in both the console logs or the network logs for either user.

I have solved the problem regarding the callback, now all the users inside the conference get notified when someone starts screen sharing.

I am facing a different problem now:
User 1 and User 2 in a conference.
User 2 starts screen sharing.
User 1 callback gets triggered, we use the contentSharing.getOutgoingScreenSharingStream but we can only see a black screen inside video element where we use the stream.
For User 2 we use the same contentSharing.getOutgoingScreenSharingStream but he can see the screenshare correctly inside the video element.

What could be the cause ? There are no errors or warnings in the logs.

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

Screen sharing is working correctly now, thank you everyone for the answers!