sipsorcery icon indicating copy to clipboard operation
sipsorcery copied to clipboard

CloseAudio on IAudioSource is no longer called on transfer

Open nick-zocdoc opened this issue 8 months ago • 5 comments

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 avatar Mar 05 '25 16:03 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()?

nick-zocdoc avatar Mar 05 '25 19:03 nick-zocdoc

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 avatar Mar 05 '25 20:03 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.

Image

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".

sipsorcery avatar Mar 05 '25 21:03 sipsorcery

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.

nick-zocdoc avatar Mar 05 '25 21:03 nick-zocdoc

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

Yes.

sipsorcery avatar Mar 05 '25 21:03 sipsorcery