Question on how a "quick cancel" is handled

[danieludy]

We have a question on how the "quick cancel" is supposed to be handled. Out setup uses a request-handler to decide how to route the invite. If we get an invite followed immediately by a cancel this results in the invite still being sent to the SRF app for handling.

Here is a sample flow:
2023-03-31 02:21:59.470933 - invite received
2023-03-31 02:21:59.471092 - 100 trying sent
2023-03-31 02:21:59.471209 - request-handler query sent
2023-03-31 02:21:59.471268 - cancel received
2023-03-31 02:21:59.471396 - 200 OK sent for cancel
2023-03-31 02:21:59.471483 - 487 sent
2023-03-31 02:21:59.472869 - response from response-handler received and invite sent to SRF app
At this point the SRF app is never notified that a cancel happened and so does the "normal" work of setting up the B2BUA. Once we have a 18X message to send back to the A leg we get an error from Drachtio because it has already been torn down.

So back to the question, is this the expected behavior? It seems to me that we would want to not send the invite to the SRF app if the call has already been cancelled as we would want to avoid the work of setting up the B leg for no reason.
If this is the expected behavior how does the SRF app know that the original call was cancelled?

[danieludy]

This looks like the same as the first issue under drachtio/drachtio-srf#113