iOS | 2.10.0

S’abonner

Patrik Spisak

• 12 avril 2024 08:43
• Modifié

Hello,

Can someone explain me why 

kTelephonyServiceDidRemoveCall is triggered after few seconds when I pick the call via Rainbow from PBX?

I did this scenario:

From PBX call to Rainbow 

I see triggered these notification in mentioned order:

1. DidAddCall (Incoming)

2. DidUpdateCall (Incoming)

3. DidRemoveCall (Incoming)

4. DidAddCall (Outgoing)

5.DidUpdateCall (Outgoing)

I have my business logic what should be done when DidRemoveCall is triggered, because before 2.10.0 was triggered only when call was ended.

How am I able to check if the call is still active? Because if I dismiss calling interface when DidRemoveCall is called I have an issue because user does not have calling interface anymore even call is still there. What do I need to check now if call still exists? I guess right now I cant rely on didRemoveCall notification.

 

0

• 

  Patrik Spisak

  • 18 avril 2024 10:14

  This is terrible support. 6 days and no answer at all.

  0

  Actions pour les commentaires Permalien
• 

  Vladimir VYSKOCIL

  • 18 avril 2024 11:39

  Patrik Spisak you question has been taken into account and has already been dispatched to the relevant developers.

  The first answers I got was that there are no logs for understanding and analyzing your issue...

  0

  Actions pour les commentaires Permalien
• 

  Vladimir VYSKOCIL

  • 18 avril 2024 14:34

  I got this answer :

  On an incoming call, you have first the WebRtc call which is presented in CallKit ; after the answer, and once the audio connection is established, we receive the PABX call (aka CSTA) with "active" state, and it replaces the WebRtc one, which is removed for UI.

  0

  Actions pour les commentaires Permalien
• 

  Patrik Spisak

  • 18 avril 2024 16:34

  And how can now verify call is really ended in this case? Before 2.10.0 was notification triggered once call has ended, so basically after 2s of this notification I dissmised my UI. 

  But now, my UI is dismissed because notification was called, but as you explained, another call is replaced previous one. 

  Is there some property or method which can I check if call is just switching from WebRTC and is not hang up? 

  0

  Actions pour les commentaires Permalien
• 

  Jean-Luc FACCHINI

  • 19 avril 2024 14:25

  Hello, sorry, I don't understand : what are you doing on 2nd addCall ? In Ucaas, we just show the new call-screen, and remove the previous one, no visible effect for the user...

  0

  Actions pour les commentaires Permalien

Vous devez vous connecter pour laisser un commentaire.