Asterisk doesn't send a BYE when doing an ARI redirect that trigger a REFER

Hello all, in my application we use ARI redirect to transfer someone from a voicemail to ringing a phone number when they press on a specific pick. The transfer work perfectly, so the phone get the invite, its ringing and when its pick up everything work correctly. Only issue Asterisk doesn’t remove itself from the call. It stay on the line. so on asterisk trigger the REFER answer to the NOTIFY but on the NOTIFY with Subscription-State: terminated;reason=noresource, Asterisk doesn’t send a BYE to disconnect itself from that leg of the call. Wondering if it’s a known issue and if there is a fix for it because from what I read about Asterisk it should normally disconnect itself. Im Sharing a SIP ladder of the call where we see the bye being send by the telephone after a while on the call with the other phone. and also a copy of the notify with header and body in case it’s missing something.
Sorry if there is not a lot of IP/info because of company policy I cannot share them. Feel free to ask me for more information if needed im gonna try to provide them if I can.

Thank you in advance

As I recall, it is up to the dialplan (or substitute, such as ARI), to hangup the that leg.

Thats what I tried to implement, tho it’s hard to follow on when to hangup that legs of the call as we don’t get the notify from asterisk on the ARI. I tried to subscribe to the ChannelTransfer and the ChannelStateChange event but none of them are getting trigger. Would you know if there is other event that are tied to the notify that I could use to decide when to hangup. Cause if its still ringing I don’t want to hangup cause it will cut the call completely and disconnect before the other side can answer

I can’t find anything in RFC 3515 that would support that assumption, and I would expect most people to use blind transfers an a fire and forget way.

We thought that we were doing it in a blind transfer way with the redirect and we were doing it as a fire and forget also, but it came back to us that asterisk wasn’t being disconnected correctly from the call when it was getting redirected. Is there another way from ARI to do a blind transfer or is it the redirect not actually doing a blind transfer?

It would seem that the documentation for the dialplan Transfer() application is wrong, and it can’t actually respond with 3xx to 6xx. It’s a thin wrapper on the channel driver transfer method, which, I assume, is also used by ARI, and that seems to return after the first attempt to send the request, so before any response has arrived.

If you have a reliable network, you should be able to hangup as soon as transfer returns, but I suppose, to allow for the worst case, you should impose a 32 second delay. Actually 16 and a bit is probably enough, as that’s when the last transmission attempt will be made, the remaining time is the time allowed to determine there is no response to that.

I haven’t checked the code deeply enough to establish whether a hangup will be held back for the reliable transmission timeout.

Alright, I might dig a little bit deeper on the blind transfer stuff from ARI, but for now what you suggested is what we implemented, so at least it will buy us some times until we maybe figure a better way that having asterisk waiting but at least its better than having it waiting on a call that it shouldn’t be. A part from this documentation Transfer Handling - Asterisk Documentation
that seems to focus more on if the customers trigger a transfer is there another one more on if asterisk trigger the transfer. Thanks