Skip to content

Conversation

@disacod
Copy link

@disacod disacod commented Nov 6, 2025

  1. When processing Cancel, the first response is 487, then OK, which is incorrect.
  2. When processing Cancel, the session hangs until the timeout with "WARN ACK missed." I think stateProceeding would be a better handler for fsm onCancel than inviteStateProcceeding.

disa and others added 4 commits November 6, 2025 11:26
First 200 OK, then 487
tx.stateProceeding better place to handle CANCEL req
@emiago
Copy link
Owner

emiago commented Nov 10, 2025

Hi @disacod .

Ok I see your point. Probably even better error handling should be done as well, but even if we fix order, your client should threat them as seperate transcations. This can indicate also bad client.
OK is for CANCEL, 487 is for INVITE.

I have to look more further, as it would be also wrong to say CANCEL is processed successfully?

@disacod
Copy link
Author

disacod commented Nov 11, 2025

Hi @emiago.
I don't know about all clients, but opensips corrects the order. I understand it's a proxy, but anyway. And although the RFC doesn't explicitly state this order anywhere (except for the section on stateful proxy), I think it's good practice to first respond with OK to the request and then respond with 487 for INVITE.
In any case, I'm not insisting; even in this form, it works well. It's just perfectionism.

@emiago emiago added the bug Something isn't working label Dec 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants