[VoIP] : l'interlocuteur n'entend pas le correspondant

[NicolasBuquet]

Au support, plusieurs témoignages disent qu'ils n'entendent pas le correspondant.

Cela ne semble pas lié à une autorisation d'accès au micro.

Cela semble lié plutôt à IntraDef pour l'instant.

https://app.crisp.chat/website/6dacc68e-de3a-4511-8177-1339616098de/inbox/session_1ba28930-fa5e-4448-92bb-b4b1d8a82bb7/ https://app.crisp.chat/website/6dacc68e-de3a-4511-8177-1339616098de/inbox/session_137d9ba9-b6ca-4064-bd54-a548e177738e/ https://app.crisp.chat/website/6dacc68e-de3a-4511-8177-1339616098de/inbox/session_86c428c7-8344-4a75-a522-228c42b15868/

Dans ce dernier ticket, l'iPhone essaie de correspondre avec un Android, qui ne l'entend pas. L'iPhone est sur un réseau wifi de l'école. Le flux sortant de l'iPhone n'est pas acheminé ?

[NicolasBuquet]

Des issues similaires existent chez Element :

• https://github.com/element-hq/element-ios/issues/7721
• https://github.com/element-hq/element-ios/issues/7609

Piste à tester : cela arrive-t-il plutôt quand l'utilisateur accepte l'appel depuis les boutons de l'UI de la timeline Tchap et moins quand l'utilisateur utilise le bouton de CallKit pour répondre ?

[NicolasBuquet]

Testé sur iOS : cela arrive quand l'utilisateur accepte l'appel entrant depuis le bouton "Décrocher" de la timeline Tchap.

Si l'utilisateur décroche avec l'un des boutons de CallKit UI, alors le correspondant est audible.

Si l'on décroche avec l'un des boutons entourés de vert, le son passe. Si l'on décroche avec le bouton entouré de rouge, le son ne passe pas.

[NicolasBuquet]

Le souci provient de la session Audio qui n'est pas prête à temps : https://developer.apple.com/forums/thread/64544 (7e post de Apple Engineer)

I am investigating the issue reported in Radar # 28774388. I believe it may be a duplicate of a known issue, and if it is this issue I suspect, then a workaround would be to configure your app's audio session (call configureAudioSession()) earlier in your app's lifecycle, before the -provider:performAnswerCallAction: method is invoked. For instance, you could call configureAudioSession() immediately before calling -[CXProvider reportNewIncomingCallWithUUID:update:completion:] in order to ensure that the audio session is fully configured prior to informing CallKit about the incoming call.

I know that the Speakerbox sample app does not do it this way (it calls configureAudioSession() from within -provider:performAnswerCallAction:), but once we fix this known issue in CallKit, that existing Speakerbox code should work as it was originally intended and this issue should no longer reproduce. In the meantime, this workaround may fix the issue.

Pour Tchap/Element, a solution est donc d'appeler [self.audioSessionConfigurator configureAudioSessionForVideoCall:call.isVideoCall] dans Matrix-iso-SDK, classe MXCallKitAdapter, méthode - (void)reportIncomingCall:(MXCall *)call :

    // If the user tap the "Answer" button from Element's timeline, very often, he can't hear the other user.
    // It's because the audio session is not configured at the beginiing of the call.
    // It's a flaw in CallKit implementation.
    // The audio session need to be configured earlier, like here.
    //
    // See https://developer.apple.com/forums/thread/64544 (7th post from Apple Engineer)
    [self.audioSessionConfigurator configureAudioSessionForVideoCall:call.isVideoCall];

    [self.provider reportNewIncomingCallWithUUID:callUUID update:update completion:^(NSError * _Nullable error) {
        if (error)
        {
            [call hangupWithReason:MXCallHangupReasonUnknownError];
            [self.calls removeObjectForKey:callUUID];
            return;
        }
    }];

[NicolasBuquet]

PR poussée chez Matrix/Element : https://github.com/matrix-org/matrix-ios-sdk/pull/1866

[NicolasBuquet]

Fixed by Tchap 2.7.9