callkit: how to differentiate decline and end call

Question

Created Dec ’16

Replies 2

Boosts 0

Views 3.9k

Participants 3

Hello everyone,

Suppose an app supports two calls at a time. the first call is connected and second call is coming in. one gets "end call & answer call", "decline", "hold call and answer call" buttons.

In case of "end call & answer call", it means to end the connected call and answer the new call.

In case of "decline", it means to reject the incomming call.

In both cases the delegate "- (void)provider:(CXProvider *)provider performEndCallAction:(CXEndCallAction *)action" is triggered. Now, How do one should know which one of those calls to end, the incoming call or the call already connected? The CXEndCallAction doesnt state a reason for either "decline" nor "end-already-connected call"

please advice on how to resolve this issue.

Boost

Answer 1

mcohen-line2 OP

Dec ’16

The CXEndCallAction includes the UUID of the call to end. Look at action.callUUID to determine which call to end.

0

Answer 2

tylerjwc OP

Mar ’23

Furthermore: Is there a way to tell that a endCallAction is part of an decline&answer instead of decline directly: In other words, is CallKit just chaining the cxendcall and cxanswercall actions without any direct indication?

Sure, you can map callUUID and check status and count of existing calls to try to infer indirectly I suppose... Is that as good as it gets? for example: If you're getting a call end for an active call, while you have a incoming call, I suppose you could assume a call answer is coming...

Callkit doesn't touch sip networking mgt, so you're still managing call status on the networking components separate from CallKit anyway. In theory, Callkit SHOULD be up to date on the actual status of the voip call, but its just a UI without direct awareness of networking, so it would be nice to know for sure that CallKit is going to hit me with a call answer right after the call end.

0