CallKit pas de son lorsque répondre deuxième appel et mettre le premier appel en attente

Question

Je suis confronté à un problème avec plusieurs appels lorsque commencer à utiliser CallKit dans mon application VoIP.

Lorsqu'il y a un appel VOIP un à un, le son fonctionne correctement. Mais une fois que l'une des parties obtient un autre appel VOIP, et choisissez de mettre en attente et d'accepter l'option; Le premier appel est mis en attente avec succès et le deuxième appel est répondu; Mais le son se ferme maintenant. Même l'échange entre les appels ne fonctionne pas non plus. L'abandon d'un appel ne fonctionne pas non plus. J'utilise RTP pour la voix.

J'ai essayé de mettre des points d'arrêt et de vérifier si la catégorie et le mode AVAudioSession sont corrects.

Dans la console, je peux vérifier à ma fin que l'appareil qui a plus d'un appel, arrêter d'envoyer des paquets sonores.

Je suis juste avant VOIP qui permet reportNewIncomingCallWithUUID et CXStartCallAction du fournisseur.

Même cas avec appel GSM. S'il y a un appel VoIP un à un avec le son est correct et que l'appel GSM est reçu d'un côté et que l'utilisateur choisit l'option Hold and Accept, le son dans l'appel GSM fonctionne correctement. Mais si l'utilisateur fait un appel VOIP comme actif et met l'appel GSM en attente en échangeant des appels, il n'y a pas de son dans l'appel VOIP. En échangeant des appels et en activant l'appel GSM, le son fonctionne à nouveau correctement. Mais pas de son pour l'appel VOIP.

Dans ce cas, nous obtenons AVAudioSessionInterruptionTypeBegan mais AVAudioSessionInterruptionTypeEnded est jamais appelé. Même après la fin de l'appel GSM.

Est-ce que quelqu'un a rencontré des problèmes similaires?

Answer 1

A eu le même problème. Si j'ai 1 appel actif, alors les nouveaux appels sont entrants, je tape hold & accepter. Nouvel appel fonctionne, mais après avoir utilisé l'échange dans CallKit audio a cessé de fonctionner. Après un long débogage trouvé l'endroit où l'audio est en train de désactiver/activer pour les appels d'échange via l'interface native CallKit - c'est provider:performSetHeldCallAction: la méthode du protocole CXProviderDelegate.

Dans mon cas, j'ai utilisé la méthode [audioController deactivateAudioSession] pour l'appel en cours OnHold.

Mais j'ai trouvé que la même méthode provider:performSetHeldCallAction: a été déclenchée pour un autre appel qui est en train d'être activé (à partir de l'état OnHold), quand appuyez sur le bouton Swap via CallKit. Donc, dans mon cas, j'ai d'abord basculer en attente d'appel (il met l'appel soit en attente ou mis en attente d'activité). Puis je vérifie quelle est la condition d'appel (en attente ou non), puis désactive ou active l'audio respectivement.

de manière commune, il semble de cette façon:

- (void)provider:(CXProvider *)provider performSetHeldCallAction:(CXSetHeldCallAction *)action { 
    SomeCallClass *call = [self.callManager callWithUUID:action.callUUID]; 
    if (!call) { 
     [action fail]; 
     return; 
    } 

    NSError *holdError; 
    [call toggleHold:&holdError]; 

    if (holdError) { 
     [action fail]; 
    } else { 

     if (call.onHold) 
      [self.audioController deactivateAudioSession]; 
     else 
      [self.audioController activateAudioSession]; 
     [action fulfill]; 
    } 
} 

Ce code devrait être dans la classe qui fonctionne en tant que délégué du fournisseur de CallKit.