Call Connection Delay When Accepting Calls in Various App States

[keshav-sf]

There is a noticeable delay when accepting a call in different app states (terminated, background, and foreground) in a Flutter application using the GetStream SDK.

Steps to Reproduce:

1. App in Terminated State:

   • Terminate the app (force quit or let it be in the background for a long time).
   • Receive an incoming call notification.
   • Accept the call.
   • Notice the delay before the call is connected.

2. App in Background State:

   • Send an incoming call while the app is running in the background.
   • Accept the call.
   • Notice the delay before the call is connected.

3. App in Foreground State (via Notification):

   • When the app is in the foreground, receive an incoming call notification.
   • Instead of accepting directly from the notification, click on it to open the screen with call details (accept/decline options).
   • Accept the call.
   • There is a delay before the call connects.

Device Information:

• Devices Tested:
  • iPhone 13, iPhone 15
• iOS Versions:
  • iPhone 13: 18.0.1
  • iPhone 15: 17.6.1
• Flutter Version: Flutter 3.24.3 (Stable)

Expected Behavior:
The call should connect immediately after being accepted, regardless of whether the app is in the background, terminated, or foreground state.

Actual Behavior:
There is a delay in connecting the call when the app is in terminated, background, or when accepting from the call screen in the foreground.

Additional Notes:

• When accepting the call directly from the notification in the foreground, the delay is significantly less.
• The issue seems to be more pronounced when the app is not in the foreground.

[d3xvn]

Hey @keshav-sf,

What kind of delay are we talking about here?
Can you give me a rough estimate of delays in all lifecycle states?

Thanks.

[dimzzky]

Hey @keshav-sf,

What kind of delay are we talking about here? Can you give me a rough estimate of delays in all lifecycle states?

Thanks.

I have same issue like this, it's around 15 - 30 second depends what phone it's use, i've try using entry level processor mediatek g36 it takes 30 seconds or more, when i use mid range processor like SD 782g it takes around 15 - 20 seconds. i found this logs

I/org.webrtc.Logging(13135): NativeLibrary: Loading native library: jingle_peerconnection_so
I/org.webrtc.Logging(13135): NativeLibrary: Loading library: jingle_peerconnection_so
I/org.webrtc.Logging(13135): PeerConnectionFactory: PeerConnectionFactory was initialized without an injected Loggable. Any existing Loggable will be deleted.
D/CompatibilityChangeReporter(13135): Compat change id reported: 263076149; UID 10245; state: ENABLED
I/AudioEffect(13135): queryNumberEffects(): *numEffects = 15, ret = 0
I/org.webrtc.Logging(13135): WebRtcAudioManagerExternal: Sample rate is set to 48000 Hz
I/org.webrtc.Logging(13135): WebRtcAudioManagerExternal: Sample rate is set to 48000 Hz
I/org.webrtc.Logging(13135): JavaAudioDeviceModule: createAudioDeviceModule I/org.webrtc.Logging(13135): JavaAudioDeviceModule: HW NS will be used.
I/org.webrtc.Logging(13135): JavaAudioDeviceModule: HW AEC will be used.
I/org.webrtc.Logging(13135): WebRtcAudioEffectsExternal: ctor@[name=main, id=2]
I/org.webrtc.Logging(13135): WebRtcAudioRecordExternal: ctor@[name=main, id=2]
I/org.webrtc.Logging(13135): WebRtcAudioTrackExternal: ctor@[name=main, id=2]
I/org.webrtc.Logging(13135): EglBase14Impl: Using OpenGL ES version 2
W/AudioCapabilities(13135): Unsupported mime audio/x-adpcm-dvi-ima
W/AudioCapabilities(13135): Unsupported mime audio/x-adpcm-dvi-ima
W/AudioCapabilities(13135): Unsupported mime audio/x-adpcm-ms
W/AudioCapabilities(13135): Unsupported mime audio/x-adpcm-ms
W/AudioCapabilities(13135): Unsupported mime audio/alac
W/AudioCapabilities(13135): Unsupported mime audio/alac
W/AudioCapabilities(13135): Unsupported mime audio/ape
W/AudioCapabilities(13135): Unsupported mime audio/ape
W/VideoCapabilities(13135): Unrecognized profile/level 32768/256 for video/mp4v-es
W/VideoCapabilities(13135): Unrecognized profile/level 32768/256 for video/mp4v-es
I/org.webrtc.Logging(13135): WebRtcAudioRecordExternal: enableBuiltInAEC(true)
I/org.webrtc.Logging(13135): WebRtcAudioEffectsExternal: setAEC(true)
I/org.webrtc.Logging(13135): WebRtcAudioRecordExternal: enableBuiltInNS(true)
I/org.webrtc.Logging(13135): WebRtcAudioEffectsExternal: setNS(true) I/org.webrtc.Logging(13135): PeerConnectionFactory: onWorkerThreadReady
I/org.webrtc.Logging(13135): PeerConnectionFactory: onNetworkThreadReady
I/org.webrtc.Logging(13135): PeerConnectionFactory: onSignalingThreadReady D/FlutterWebRTCPlugin(13135): onConnectionChangeCLOSED

like it's load some libraries,

[keshav-sf]

Hey @keshav-sf,

What kind of delay are we talking about here? Can you give me a rough estimate of delays in all lifecycle states?

Thanks.

Hi @deven98,

Thanks for your prompt reply!

When the callee (receiver) accepts the call while the app is in the background, it typically takes around 1 to 3 seconds to redirect to the call screen. Meanwhile, the caller is redirected from the outgoing call screen to the call screen almost instantly after the call is accepted.

Even after both parties are redirected to the call screen, there's still a noticeable delay in voice transmission between the two. For us, the overall delay is mostly around 3 to 4 seconds, but our client has reported delays of approximately 15 to 30 seconds, which is quite concerning for us. While we haven't been able to reproduce such long delays on our end, we suspect it might be due to different network conditions or regions.

We'd appreciate any further insights into why this might be happening, and whether there are any network-related optimizations we can make.

Thanks again for your help!

[renefloor]

@keshav-sf In recent versions we made some improvements for the call connection. Is this issue solved for you, or are you still having connection delays?