Recover failed blind transfer

Asterisk Asterisk SIP
#1

Hi,

I was wondering is there a way to make Asterisk blind transfer using REFER supporting the following scenario (Asterisk is the Transferee) like if the transfer agent is busy with response 486 to have it in the notify sipfrag so Transferor can re-invite back the original dialog to recover the call after the failed transfer.

Transferor providing the Transfer Target’s contact information to the Transferee (Asterisk). The Transferee (Asterisk) attempts to establish a session using that contact and reports the results of that attempt to the Transferor. The signaling relationship between the Transferor and Transferee is not terminated, so the call is recoverable if the Transfer Target cannot be reached.

I’d like to have the exact scenario like in https://tools.ietf.org/html/rfc5589#page-15

I turned on debugging and received the REFER message from the Transferor but Asterisk treats this blind transfer as fire and forget and soft-hang the channel.

[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: Received request
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: Method is REFER
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_refer.c: Created progress monitor '0x7fea531a4748' for transfer occurring from channel 'PJSIP/team-000000a1' and endpoint 'team'
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_refer.c: Accepting REFER request for progress monitor '0x7fe9a40196f0'
[Nov 22 04:30:17] DEBUG[24120] res_pjsip/pjsip_message_filter.c: Re-wrote Contact URI host/port to 209.135.217.186:5060 (this may be re-written again later)
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: Function session_inv_on_tsx_state_changed called on event TSX_STATE
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The state change pertains to the endpoint 'team(PJSIP/team-000000a1)'
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The inv session does NOT have an invite_tsx
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The UAS REFER transaction involved in this state change is 0x7fe9f4085cb8
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The current transaction state is Completed
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The transaction state change event is TX_MSG
[Nov 22 04:30:17] DEBUG[24120] res_pjsip_session.c: The current inv state is CONFIRMED
[Nov 22 04:30:17] DEBUG[24120] parking/parking_bridge_features.c: Checking if 9725980143@transfer_to_pstn is a parking exten
[Nov 22 04:30:17] DEBUG[2728] devicestate.c: No provider found, checking channel drivers for PJSIP - pstn
[Nov 22 04:30:17] DEBUG[2728] devicestate.c: Changing state for PJSIP/pstn - state 2 (In use)
[Nov 22 04:30:17] DEBUG[24120] bridge_channel.c: Setting 0x7fea4800d2f0(PJSIP/team-000000a1) state from:0 to:2
[Nov 22 04:30:17] DEBUG[2757] app_queue.c: Device 'PJSIP/pstn' changed to state '2' (In use) but we don't care because they're not a member of any queue.
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge_native_rtp.c: Bridge '7a7da3ff-3540-4a6d-8bd0-1085a4b0da15'.  Checking compatability for channels 'PJSIP/pstn-000000a2' and 'PJSIP/team-000000a1'
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge_native_rtp.c: Bridge '7a7da3ff-3540-4a6d-8bd0-1085a4b0da15' can not use native RTP bridge as channel 'PJSIP/pstn-000000a2' has features which prevent it
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge.c: Bridge technology native_rtp is not compatible with properties of existing bridge.
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge.c: Bridge technology holding_bridge does not have any capabilities we want.
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge.c: Bridge technology softmix does not have any capabilities we want.
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge.c: Chose bridge technology simple_bridge
[Nov 22 04:30:17] DEBUG[25423][C-00000043] bridge.c: Bridge 7a7da3ff-3540-4a6d-8bd0-1085a4b0da15 is already using the new technology.
[Nov 22 04:30:17] DEBUG[25423][C-00000043] channel.c: **Soft-Hanging (0x02) up channel 'PJSIP/pstn-000000a2**'

Thanks in advace,

#2

This is not currently supported.

#3

Any future plans to get it supported ?

#4

I know of noone actively working on such a thing.

#5

I’m just curious if you have you found a solution to this yet? We are having exactly the same problem. It seems like this would be a common scenario in transfers, and it’s surprising that it isn’t supported. So, I’m suspicious that I’m just going about this the wrong way.

Here’s our scenario:

Alice calls in to the Asterisk system, and we connect her to Bob (which is another PBX).
Bob wants to transfer Alice to Carol, so Bob sends Asterisk a REFER.
Asterisk gets the REFER from Bob (the transferor), and it handles that by entering the dialplan at the extension specified in the Refer-To.
At that point in the dialplan, we just call Dial to connect Alice with Carol.
If Carol answers, everything works just fine. Bob gets a NOTIFY sipfrag 200 and correctly decides that he is finished and sends a BYE.
However, if Carol is 486 BUSY or doesn’t answer in time, the Dial app returns and Asterisk steps to the next line in the dialplan. When it gets to the end of the dialplan for that extension, it hangs up…on Alice.

But just because Carol is busy doesn’t mean I want to hang up on Alice. She should still be able to continue her conversation with Bob (who never hung up and was waiting for the transfer to complete).

So, it seems like there should be something I can add as the last step in the dialplan to tell Asterisk to allow Alice and Bob to continue their conversation instead of hanging up on Alice.

#6

Hi Jwilhite,

It has nothing to do with dialplan , I tried many options there and channels were hanged up before like shown in my debug above by soft hanging the channel , Asterisk treats blind transfer as fire and forget and don’t keep the original channel/bridge up.

I didn’t find yet a solution but I might change the whole engine for that option :frowning:

#7

Although Transfer returns quickly, I don’t think the original session is dropped until either running off the end of the dialplan, or an explicit Hangup.

#8

From the debug log the bridge is dissolved and channel is soft-hanged , yes the BYE is delayed but the channel is not there anymore.

check the following debug snip once I got the REFER the channel is soft-hanged.

[Nov 22 04:30:17] DEBUG[24120] res_pjsip_refer.c: Accepting REFER request for progress monitor '0x7fe9a40196f0'
[Nov 22 04:30:17] DEBUG[25423][C-00000043] channel.c: **Soft-Hanging (0x02) up channel 'PJSIP/pstn-000000a2**'
#9

David,

That’s right. The original session isn’t dropped until you run off the dialplan or hangup. However, the channel with transferor is destroyed. I can certainly call Wait() in the dialplan and Asterisk doesn’t hang up on the caller until the wait is over, but that doesn’t really help me any. I want to give the call back to the transferor when the transfer fails.

RFC 5589 seems to say that this should be possible:

6.3. Failed Transfer
This section shows examples of failed transfer attempts. After the transfer failure occurs, the Transferor takes the Transferee off hold and resumes the session.

It sounds like this isn’t implemented in Asterisk, though. If not, is there some other way to give the call back to a transferor if the transfer fails?

I really need this functionality because we are using Asterisk to replace a system that was able to do this. Are there architectural reasons that this behavior isn’t implemented? Or is it just because users rarely need to do this? I’m certainly willing to dig into the Asterisk source and try to make this work unless someone knows a good reason that Asterisk shouldn’t be able to do this (or why doing it might be a formidable task).

#10

The core, the transfer functionality, and the channel drivers just aren’t explicitly written to support such a thing. Blind transfer is merely a “go to this place in the dialplan” which works fine for many. Even the functionality in PJSIP that allows relaying the status of that uses other functionality to know what is going on, as there is no monitoring built in.

It might be possible to cobble stuff together to make it work, but it’s uncharted territory.

#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.