RE: [Iaxclient-devel] IAX2 blind transfer appears to fail when calls are native bridged

[Steven S. <ss...@so...>]

> That's not strange, that's the expected behavior.  In order to transfer
> when a call is directly going between endpoints, it will be necessary toe
> execute a supervised transfer.
> 
> Mark

Ok, that makes sense for IAX2-to-IAX2 transfers.  Where I get lost is in
executing a transfer where the destination party (the person you want to
transfer _to_) is not an IAX2 channel.  I have a mixed test environment
including a number of SIP devices.  Let me see if I get this right...

1.  An original call exists between my IAX2 device (A) and another IAX2
device (B).  The call is established via Asterisk, which drops out of the
call once the native transfer has been successfully established.

2.  I decide to transfer party (B) to another extension which is a SIP
device on my local Asterisk, we'll call it (C).

3.  I place (B) on hold and establish a call to (C) through Asterisk.  (C)
answers the call.  **IN THIS CASE, FROM A TRANSFER PERSPECTIVE, (C) IS NOT
THE SIP PHONE, BUT IS ACTUALLY THE ASTERISK WHICH IS CONVERTING PROTOCOL AND
AUDIO TO SIP??

4.  I (A) send a TXREQ to (B).
5.  I (A) send a TXREQ to (C).
6.  (B) sends a TXCNT to (C).
7.  (C) sends a TXCNT to (B).

If all goes well...

8.  (C) sends a TXACC to (B).
9.  (B) sends a TXACC to (C).
10. (B) sends TXREADY to (A).
11. (C) sends TXREADY to (A).
12. (A) sends TXREL to (B).
13. (A) sends TXREL to (C).

14+.  I assume that once this completes both IAX2 on (A) releases both calls
(the 'HELD' call to (B) and the active call to (C)) and returns to an IDLE
state.

If all does not go well...?

It would appear that the audio has to bridge through the IAX client (A)
(which is acting as a server, but hey, client, server, what's the difference
in a peer to peer scenario... ;-).  What I guess I need to get my mind
around is how to handle scenarios where the native bridge fails in steps
8/9.  How do we avoid (A) being forced to remain on-line to bridge (B) and
(C).  This really should be the job of the PBX rather than an end-point like
the client.

This may just be my limited brain trying to work through a scenario that is
beyond it's capacity.  If this is the case, please let me know and I'll just
code it up and see what happens.

Thanks,

Steve