Missed call notification not received when call times out unanswered

[mabayon]

What did you do?

When a call is not answered by the user on the mobile side, I let the call reach its ringing timeout naturally (without explicitly rejecting it). I expected to receive a missed call push notification after the timeout expired.

What did you expect to happen?

A call.missed event should be fired and a missed call push notification should be delivered to the callee's device when the call times out unanswered — consistent with the behavior described in the GetStream documentation.

What happened instead?

No missed call notification is received when the call times out on the mobile side.

However, if the caller (web agent) hangs up before the timeout, the missed call notification is received correctly.

After investigating, the root cause appears to be that the Swift SDK is automatically sending a decline reason when the call times out unanswered. According to the GetStream documentation, the call.missed event is only triggered when the rejection reason is timeout or busy — not decline. This prevents the call.missed event from firing.

curl 'https://video.stream-io-api.com/video/call/default/*/reject?api_key=&connection_id=' \
-X POST \
-H 'Host: video.stream-io-api.com' \
-H 'Accept: */*' \
-H 'Authorization:' \
-H 'X-Stream-Client: stream-video-swift-v1.44.0|app=|app_version=|os=iOS -|device_model=iPhone13,2' \
-H 'stream-auth-type: jwt' \
-H 'Accept-Language: fr-FR,fr;q=0.9' \
-H 'User-Agent: /7 CFNetwork/3860.500.111 Darwin/25.4.0' \
-H 'Connection: keep-alive' \
-H 'x-client-request-id:' \
-H 'Content-Type: application/json' \
--data-raw '{"reason":"decline"}' \

The reason should be timeout in this scenario, not decline.

GetStream Environment

GetStream Video version: 1.44.0
GetStream Video frameworks: StreamVideo
iOS version: iOS 26
Swift version: Swift 6
Xcode version: Xcode 26
Device: iPhone 12

Additional context

• The missed call notification works correctly when the web agent ends the call before the timeout, confirming the server-side call.missed logic is functioning correctly.
• The issue is isolated to the reason code sent by the Swift SDK on the callee side when a call times out unanswered.
• Expected fix: the SDK should send reason: "timeout" instead of reason: "decline" when auto-rejecting a timed-out call.

[ipavlidakis]

Hi @mabayon,

Thanks for reaching out about this issue. I just tried this scenario in our DemoApp (which is in this repo) and i was able to inspect the SDK sending the right rejection reason on timeout and the missed push notification arriving.

In order to be able to understand better what it's happening on your side, can you answer the following questions:

• are you using CallKit and/or the CallViewModel?
• if you are using CallKit do you have any overrides for the CallKitService? If yes, can you share the code?
• in your scenario, what's the state of the app? Is it running in the foreground, background or is the screen locked?

If you could also share some logs of a call where you reproduced this problem that will greatly help (make sure to activate the SDK's debug logs by calling LogConfig.level = .debug in your appDelegate on Window.onAppear).

Best regards,
Ilias

[ipavlidakis]

Hey @mabayon,

As a follow-up, I now see what you mean in your message. You were referencing the reason on the caller side that is set to cancel. I'll need to check if that needs to be changed but regardless of it the callee is already sending a rejection event with reason timeout which is enough for the push notification to trigger.

Your answers to my questions above will help us understand better what's going on.

Best regards,
Ilias

[mabayon]

Hi @ipavlidakis, thanks for the follow-up. Here are the answers to your questions:

Are you using CallKit and/or CallViewModel?
Yes, we use both. We use the SDK's CallKitAdapter via @Injected(\.callKitAdapter) — we call callKitAdapter.registerForIncomingCalls() after initializing StreamVideo. We also use CallViewModel from StreamVideoSwiftUI for the in-call UI. We have no custom CallKitService subclass or override — we rely entirely on the SDK's default CallKit handling.

App state during failure?
The issue occurs regardless of app state — foreground, background, and locked screen. The missed call notification never arrives when the call times out naturally.

Debug logs:
I've attached debug logs (with LogConfig.level = .debug) from a reproduce where I let the call ring until timeout. The key lines are:

[CallKitService.swift:571] [provider(_:perform:)] > Ending VoIP call with callId:019d4944-bc42-7015-a1f1-2e578e81b66f
[CallKitService.swift:594] [provider(_:perform:)] > Rejecting with reason: decline
[Call.swift:480] [reject(reason:)] > Transition Call:IdleStage:idle → Call:RejectingStage:rejecting

As you can see, when the call times out, the SDK's own CallKitService sends a rejection with reason decline instead of timeout. This is happening inside CallKitService.swift:594 in the provider(_:perform:) callback — the CXEndCallAction from CallKit triggers a reject with the wrong reason.

Our StreamVideo initialization:

StreamVideo(
    apiKey: key,
    user: user,
    token: .init(stringLiteral: userInfo.token),
    pushNotificationsConfig: .make(
        pushProviderName: "ios-apn-\(env)",
        voipProviderName: "ios-voip-\(env)"
    )
)

We register both VoIP tokens (via callKitPushNotificationAdapter.$deviceToken → streamVideo.setVoipDevice()) and APNs tokens (via streamVideo.setDevice()).

Full debug logs:

2026-04-01 15:39:56.979 [DEBUG] [io.getStream.video.core.web_socket_engine_queue] [URLSessionWebSocketEngine.swift:127] [doRead()] > Received webSocket message:{
  "custom" : {

  },
  "type" : "health.check",
  "connection_id" : "REDACTED",
  "created_at" : "2026-04-01T13:39:51.911033258Z"
}
2026-04-01 15:39:56.980 [INFO] [io.getStream.video.core.web_socket_engine_queue] [WebSocketClient.swift:229] [webSocketDidReceiveMessage(_:)] > Received webSocket event coordinator: health.check.
2026-04-01 15:39:56.980 [DEBUG] [io.getStream.video.core.web_socket_engine_queue] [WebSocketClient.swift:261] [handle(healthcheck:info:)] > Handling healthcheck
2026-04-01 15:39:56.981 [DEBUG] [io.getStream.video.core.web_socket_engine_queue] [EventNotificationCenter.swift:26] [process(_:postNotifications:completion:)] > Processing webSocket events: [coordinator: VideoEvent { typeHealthCheckEvent:HealthCheckEvent { connectionId:REDACTED, createdAt:2026-04-01 13:39:51 +0000, type:health.check } }]
2026-04-01 15:39:56.981 [INFO] [io.getStream.video.core.web_socket_engine_queue] [WebSocketPingController.swift:101] [pongReceived()] > WebSocket Pong
2026-04-01 15:39:56.981 [INFO] [io.getStream.video.core.web_socket_engine_queue] [WebSocketPingController.swift:77] [connectionStateDidChange(_:)] > Resume WebSocket Ping timer
2026-04-01 15:39:56.982 [INFO] [io.getStream.video.core.web_socket_engine_queue] [WebSocketClient.swift:26] [connectionState] > Web socket connection state changed: connected(healthCheckInfo: StreamVideo.HealthCheckInfo(coordinatorHealthCheck: Optional(HealthCheckEvent { connectionId:REDACTED, createdAt:2026-04-01 13:39:51 +0000, type:health.check }), sfuHealthCheck: nil))
2026-04-01 15:39:57.220 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [CallKitService.swift:571] [provider(_:perform:)] > Ending VoIP call with
callId:019d4944-bc42-7015-a1f1-2e578e81b66f
callType:default
callerId:REDACTED
2026-04-01 15:39:57.222 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [CallKitService.swift:594] [provider(_:perform:)] > Rejecting with reason: decline
call:019d4944-bc42-7015-a1f1-2e578e81b66f
callType: default
2026-04-01 15:39:57.267 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [Call.swift:480] [reject(reason:)] > Transition Call:IdleStage:idle → Call:RejectingStage:rejecting
2026-04-01 15:39:57.353 [DEBUG] [io.getStream.video.core.web_socket_engine_queue] [URLSessionWebSocketEngine.swift:127] [doRead()] > Received webSocket message:{
  "user" : {
    "id" : "REDACTED",
    "role" : "user",
    "online" : true,
    "name" : "REDACTED"
  },
  "call_cid" : "default:019d4944-bc42-7015-a1f1-2e578e81b66f",
  "call" : {
    "type" : "default",
    "backstage" : true,
    "cid" : "default:019d4944-bc42-7015-a1f1-2e578e81b66f",
    "id" : "019d4944-bc42-7015-a1f1-2e578e81b66f",
    "settings" : {
      "ring" : {
        "incoming_call_timeout_ms" : 100000,
        "missed_call_timeout_ms" : 150000,
        "auto_cancel_timeout_ms" : 100000
      }
    },
    "session" : {
      "rejected_by" : {
        "REDACTED" : "2026-04-01T13:39:57.298155458Z"
      },
      "participants" : [
        {
          "user" : {
            "id" : "REDACTED",
            "role" : "admin",
            "name" : "REDACTED"
          }
        }
      ],
      "missed_by" : {

      }
    },
    "created_by" : {
      "id" : "REDACTED",
      "role" : "admin",
      "name" : "REDACTED"
    }
  },
  "reason" : "decline",
  "type" : "call.rejected",
  "created_at" : "2026-04-01T13:39:57.304023291Z"
}
2026-04-01 15:39:57.358 [INFO] [io.getStream.video.core.web_socket_engine_queue] [WebSocketClient.swift:229] [webSocketDidReceiveMessage(_:)] > Received webSocket event coordinator: call.rejected.
2026-04-01 15:39:57.358 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [CallCache.swift:61] [remove(for:)] > Will remove call:default:019d4944-bc42-7015-a1f1-2e578e81b66f
2026-04-01 15:39:57.358 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [CallCache.swift:64] [remove(for:)] > CallCache count:0.
2026-04-01 15:39:57.358 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [Call.swift:480] [reject(reason:)] > Transition Call:RejectingStage:rejecting → Call:RejectedStage:rejected
2026-04-01 15:39:57.358 [DEBUG] [com.apple.root.user-initiated-qos.cooperative] [Call.swift:117] [deinit] > Call cID:default:019d4944-bc42-7015-a1f1-2e578e81b66f is deallocating...

[ipavlidakis]

Hey @mabayon,

From your log there doesn't seem to be a timeout (there are log entries that i would expect to see when a timeout occurs). I'm trying that internally using our DemoApp and I can see the expected behaviour (letting the call ring timeout on the callee side is rejecting the call with reason .timeout).

Do you mind trying again and see if you can get different logs? Maybe a video recording of the device accepting the call may help us understand what's happening on device.

Best regards,
Ilias

[mabayon]

Hi @ipavlidakis,

It seems related to the timeout set above 30s. If the timeout we set in the Dashboard is greater than 30s, the reason sent is decline, and if it's set below 30s, the correct reason is sent.