Add Large Gallery Fails with DiagCode: 404#5152 on p2p calls

[1fabi0]

Describe the issue The Recording Application I have adds Large Gallery Bot for Participant Video feed (to have up to 50 Video Streams in one Combined).

But I have an issue in the following scenario

Two users under Policy start a p2p call/ user A calls user B: as soon as user B accepts the call user A is forwaded to voicemail and no call between the two parties is initiated, voicemail can be recorded just fine.

My logs show an exception of the AddLargeGallery() Method

exception: Code: 404
      Message: Unexpected 'Failed' status for operation 84630ecd-a5a8-4839-8dda-4575b3e0cc3d:
Not Found. DiagCode: 404#5152.@
      AdditionalData:
        subcode: 5152

@samarthasthana @zhengni-msft @ssulzer

• What is subcode 5152?
• What should I do to avoid this error?
• Why does this error cancel the whole call? (I would expect it just stops adding the LargeGalleryApplication)

Graph SDK (please complete the following information):	Package	Version
Micrsoft.Skype.Bots.Media	1.27.0.2-alpha
Microsoft.Graph.Communications.Calls	1.2.0.7270
Microsoft.Graph.Communications.Calls.Media	1.2.0.7270

Call ID

• 781f5c00-ab72-4d8d-89e2-be110c58261d at 2024-02-27T09:03 UTC

[Hunterjet]

5152 is a Conversation Service subcode. It means "Failure querying object from remote store." The root cause is that the call had already ended.

[Hunterjet]

To be more precise, the call ended 9 milliseconds after the addLargeGalleryView request arrived.

[InDieTasten]

@Hunterjet Is there also an explanation as to why it would be ended after adding the large gallery view bot? It's a reproducable behavior on our end.

[1fabi0]

Thanks @Hunterjet. Also I now found, if I wait for other participants than the bot itself to join and then add the large gallery it works as expected. So I assume there is some issue with large gallery added to p2p calls before any other participant is connected, even though the call of the bot shows it's established.

[InDieTasten]

The behavior is definitely not what I would expect. Could this still be a bug in the Teams platform?

[Hunterjet]

@InDieTasten @1fabi0 I might be misunderstanding the scenario. From looking at the call logs it seems to me that the reason the call went to voicemail is that one of the users rejected the call. It seems to be completely unrelated to the AddLargeGalleryView request. Are you saying this rejection didn't actually happen? If so could you elaborate on what the Teams Client behavior is for these two users? Does one of the user not pick up the incoming call? Could the call be timing out, or does it end unnaturally when the AddLargeGalleryView request is sent? What happens if the user picks up the incoming call, does it still end? Does it end while being established?

[1fabi0]

@Hunterjet user b answers the call and user A is immediately forwarded to voicemail it seems very much related to answering as user b can vary the timing for accepting/answering the call. Also it seems that the call end unnaturally when the AddLargeGalleryView is called, because without the AddLargeGalleryView it works fine( I would have to replay the scenario to log which users bot AddLargeGalleryView is called first etc.)

Also as I mentioned if the Bot waits for other participants to join, it also works fine.

Maybe some more info's about the logical setup of the recording bot:

As soon as call established: AddLargeGalleryView Does not work

As soon as call established: Does the participant list contain a participant that has other participant id than recorders participant ID? yes: AddLargeGalleryView No: wait for participant list Update -> recheck participant list and if there is an additional participant now: AddLargeGalleryView Does work

If you have any further questions please do not hesitate to ask, I would be happy to find the issue here 😃

[Hunterjet]

@1fabi0 Thanks for the extra information! We did an investigation of this call in the back end and couldn't find anything unusual about it. Would it be possible for you to collect Teams client logs for the user that accepts the incoming call in the failure case? Let me know if you need some help to figure out how to do that. With that we can continue the investigation from the client side.

I also just want to confirm that I'm understanding the scenario correctly: for call 781f5c00-ab72-4d8d-89e2-be110c58261d, the user accepted the incoming call in the Teams client, but the calling user was sent to voicemail regardless.

[1fabi0]

@Hunterjet yes correct but both users in the scenario had the same policy assigned, and I'm not sure of which of the two users the mentioned bot call had this AddLargeGallery Error with code 5152.

I will try to collect the teams logs in the next few days.

[1fabi0]

@Hunterjet I retried this today, to do the logging, now I don't have any problems with calling AddLargeGalleryAsync directly 🤔