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

[Adam H. <ad...@te...>]

Unfortunately, iaxlib doesn't initiate native transfers, that 
functionally is only asterisk atm - in this case, the client (A) would 
proxy regardless. Please implement it :) But lets assume that iaxlib had 
it - the answer to your question, yes, the client should proxy it. If 
the remote parties can reach each other directly, no worries, otherwise 
you're the only way to connect the calls - you can't hand ball that off 
to a PBX (as they might not be able to reach the PBX). As you said, it's 
peer to peer, asterisk is no different to libiax2 clients in a call.

Did that make sense, I apologize if it doesn't

-Adam


Steven Sokol wrote:

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