Using AnswerAsync() with Task.Run() causes the mediasession to be

[half2me]

Describe the issue We tried to wrap call.AnswerAsync() inside of Task.Run() and it resulted in an issue where the MediaSession on a ICall was often null instead of the expected value.

Code Snippet This code works as expected

ICommunicationsClient client;
client.Calls().OnIncoming += CallsOnIncoming;
client.Calls().OnUpdated += CallsOnUpdated;

private void CallsOnIncoming(ICallCollection sender, CollectionEventArgs<ICall> args)
{
  foreach (var call in args.AddedResources)
  {
    if (callShouldBeAccepted()) // business logic to decide if we answer or reject
    {
      // Here we answer the call:
      ILocalMediaSession session = CreateMediaSession(/*...*/);
      call.AnswerAsync(session, /*...*/);
    } else {
      // Here we reject it
      call.RejectAsync(RejectReason.Forbidden);
    }
  }
}

private void CallsOnUpdated(ICallCollection sender, CollectionEventArgs<ICall> args)
{
  foreach (var call in args.AddedResources)
  {
    // rejected calls also show up here for some reason, so we filter those:
    if (call.MediaSession is null)
    {
      // rejected calls don't have a MediaSession
      _logger.LogInformation("Skipping call init (no MediaSession)");
      continue;
    }
    // otherwise, handle the call as usual...
    // <call handling logic here>
  }
}

Adding Task.Run() breaks things

Task.Run(async () => await call.AnswerAsync(session, /*...*/));

Now the MediaSession is often null for calls that we answered. And we see this in the logs:

Skipping call init (no MediaSession)
Skipping call init (no MediaSession)
Skipping call init (no MediaSession)

In our testing, it happens approximately 15-30% of calls, but this varies. My guess is an issue due to the task being scheduled on a different thread.

Expected behavior It should behave the same way it did before using Task.Run()

Graph SDK (please complete the following information):

• Version 1.31.0.225 (but the issue is the same with older versions)

Call ID Provide the list call ids that encountered this issue. Include the time in UTC/GMT when these call have occurred.

Logs If required, please add logs from the SDK. (Please remove any PII from the logs before uploading)

Additional context Add any other context about the problem here.

[InDieTasten]

That is normal behavior afaik. It sometimes takes a couple of call updates to get the media session ready. You just need to code your use of the media session defensively.

[half2me]

@InDieTasten if thats the case, is there any way to know on the Calls().OnUpdated event if the call was rejected or not? The only reason we do this check is because rejected calls also show up here for some reason. If we can differentiate between them another way, I can remove this check.

[InDieTasten]

@half2me I am unsure of that. I would suggest debugging and looking through the various properties and additional data fields of the ICall / Call resource

[ADelYerro]

Your guess is right, the moment you do

 call.AnswerAsync(session, /*...*/);

in a separate thread, you are creating a race condition with OnUpdated which you can't handle, since it runs in the background in the SDK.

By the time AnswerAsync finishes (which wires the MediaSession into the statefulCall) you are already receiving events in OnUpdated, since you are threading on your side the already threaded async call using Task.Run.

Basically you are receiving events from the call, before CreateMediaSession finishes. So yeah, don't do that, and ensure the MediaSession finishes its instantiation before you Answer the call.