CloseAudio on IAudioSource is no longer called on transfer

[nick-zocdoc]

Hi, I implemented IAudioSource and do some cleanup in my implementation of the CloseAudio() method. I recently upgraded my SipSorcery package from 6.x to 8.x and it seems the CloseAudio() method is no longer called when I do a userAgent.BlindTransfer().

It is still called if the counterparty hangs up, i.e. a SIP BYE message is received. So I have some indication that I haven't messed up the interface signature or anything. Any idea why CloseAudio() wouldn't be called on Transfer? Thanks!

[nick-zocdoc]

After further research it looks like a bunch of timers and objects stay active after BlindTransfer because CallEndedSynchronized() is never invoked. I can't explicitly call Hangup() after BlindTransfer() because it will then send more SIP messages to the counterparty after the transfer SIP messages. What's the right way to end and cleanup a call after BlindTransfer()?

[sipsorcery]

It looks like a bug might have been introduced. The SIPUserAgent class should send the BYE request to hangup once it gets the 202 accepted response for the blind transfer. It does not appear to be doing that.

This docs page shows how the SIP flow should work.

[sipsorcery]

Actually looks like the "bug" might have always been there. This blind transfer test scenario from circa 5 years ago has the transferee hanging up the call.

The SIP REFER spec does indicate the Transferor can hangup as soon as the REFER is accepted if "it wishes". The trade-off being that if the blind transfer fails the original call is gone and there is no recovery option.

To avoid breaking anybody that might be relying on the existing behaviour I should be able to add a new optional parameter to the BlindTransfer method that facilitates support for the officially recommended behaviour.

Each of the flows below shows the dialog between the Transferor and
the Transferee remaining connected (on hold) during the REFER
process. While this provides the greatest flexibility for recovery
from failure, it is not necessary. If the Transferor's agent does
not wish to participate in the remainder of the REFER process and has
no intention of assisting with recovery from transfer failure, it
could emit a BYE to the Transferee as soon as the REFER transaction
completes. This flow is sometimes known as "unattended transfer" or
"blind transfer".

[nick-zocdoc]

Thanks for the quick response! It sounds like I can just do userAgent.Hangup() after I call userAgent.BlindTransfer() as long as the result is true? And then I'd be compliant with the spec and you don't need to change any code, is that right? I'm happy to just use that solution on my end.

[sipsorcery]

It sounds like I can just do userAgent.Hangup() after I call userAgent.BlindTransfer() as long as the result is true?

Yes.