SIPUserAgent does not send BYE under specific conditions.

[thicsilva]

After the SIPUserAgent makes an outgoing call and sends a CANCEL, if it answers an incoming call and hangs up, the BYE signal will not be sent. Example:

{
    SIPTransport aliceTransport = new SIPTransport();
    aliceTransport.AddSIPChannel(new SIPUDPChannel(IPAddress.Loopback, 0));
    var alice = new SIPUserAgent(aliceTransport, null, true);
    SIPServerUserAgent uas = null;
    alice.OnIncomingCall += (ua, req) => uas = ua.AcceptCall(req);
    SIPTransport bobTransport = new SIPTransport();
    bobTransport.AddSIPChannel(new SIPUDPChannel(IPAddress.Loopback, 0));
    SIPServerUserAgent uasBob = null;
    var bob = new SIPUserAgent(bobTransport, null, true);
    bob.OnIncomingCall += (ua, req) => uasBob = ua.AcceptCall(req);    
    _ = bob.Call(alice.ContactURI.ToString(), null, null, CreateMediaSession());
    await Task.Delay(500);
    bob.Cancel();
    await Task.Delay(500);
    _ = alice.Call(bob.ContactURI.ToString(), null, null, CreateMediaSession());
    await Task.Delay(500);
    _ = bob.Answer(uasBob, CreateMediaSession());
    await Task.Delay(500);
    bob.Hangup();
}

According to the example, after the Hangup, Bob and Alice should have their dialogues nullified, and they should no longer have an active call, right?
Probably what happens is that after the Cancel, the SIPClientUserAgent (m_uac) created in InitiateCallAsync, as well as the SIPCallDescriptor (m_callDescriptor), will not be cleared (a very simplistic view of the likely problem).
So when performing a Hangup, it will always attempt to Hangup the SIPClientUserAgent, whose Dialog is null.

[sipsorcery]

You can't double up the user agent like that. You should create a new user agent instance for each call. In your example you are using bob to call Alice and then later the same bob UA to receive a call from Alice. You should use a new UA instance to receive the call from Alice and same goes for the alice UA, use different instances for the receive and subsequent call.

[thicsilva]

Okay, but if we use the SipSorcery.Softphone application as an example, we only have one UA registered per instance creation of the SIPClient, right?
Imagine the scenario where Bob is authenticated in the Softphone application and Alice is authenticated in another location using any application (MicroSip for example).
Bob makes a call to Alice and cancels.
Alice makes a call to Bob and he answers.
Bob hangs up.
From then on, Alice will not receive a BYE, her call will be terminated by timeout.
Shouldn't Alice receive a BYE?

[sipsorcery]

Yes, but in the softphone's case the SIPClient is where the single simultaneous call contraint is being enforced. See SIP_CLIENT_COUNT.

Shouldn't Alice receive a BYE?

Your scenario referes to two indepedent, and as far as teh SIP protocol is concerned, separate calls. Alice should definitely receive a BYE for the second call, the one she initiated to Bob and that he answered.

Alice will NOT receive a BYE on the first call, the one form Bob to her, as she never answered. Instead she will get a CANCEL reqeust to indicate that Bob ended the call attempt.

[thicsilva]

I understand that Alice will not receive a BYE on the first call due to the CANCEL.
The problem I'm referring to is precisely on the second call, initiated by Alice, where Bob answers and hangs up.
The moment Bob hangs up, the UA Hangup is triggered, where theoretically a BYE should be sent, but this BYE is not sent. The call on Bob's side is terminated, but on Alice's side the call continues, being terminated some time later. Looking at Wireshark, the BYE request comes from Alice some time after Bob's Hangup.