Possible steps to reproduce this:
1. Run a packet sniffer.
2. Place a SIP call.
3. Instantly, almost simultaneously with starting the call press <ESC>
to hang up the call.
4. Repeat until no CANCEL has been send after INVITE.
This may be a bit harder when one is not fast enough, and the
connection to the SIP Proxy is. In my case I've used netem in tc to
selectively delay datagrams sent from the server in order to observe
what causes the CANCEL not to be sent. But on slow links this can
easily happen in normal "I've changed my mind" case.
So what happens is that when I hang up the call when there was no
provisional reply seen, Jitsi closes the call window immediately and
that's it. Afaik UAC should not send the CANCEL before provisional
reply, so this is partly fine. What I would expect is that Jitsi
remembers the session for e.g. normal call time-out and sends the
CANCEL right after the reply comes in. Or BYE if it happens to be '200
What we have now is that Jitsi is completely ignoring any further
transmission regarding same Call-ID, so that after hanging up from
Jitsi, Jitsi receives '100 trying' (the proxy in my case is Kamailio,
so this is the first thing it sends), then '180 ringing'. The other
side is ringing, so I can answer the call. This causes the other side
to send '200 Answering' multiple times, until it times out, then it
starts sending BYEs, again until it times out, as everything received
by Jitsi is being ignored.