I’m trying to set asterisk up such that a callee can move the caller to another number by either pressing a code within the call or calling a specific extension.
I’ve found some references to what I want in features.conf(the “prefix” to initate a transfer) and in the (Blind/Attended)Transfer functions, but I’m not quite sure of how to use either.
The current extensions.conf for testing is rather simple:
exten => _*1X.,1,NoOp("Exten: ${EXTEN:2}")
same => n,BlindTransfer(${EXTEN:2})
exten => _1XX,1,NoOp("Call: ${CALLERID(num)}")
same => n,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},Tt)
same => n,Hangup()
But it seems I’m going in the wrong direction, as calling *1<number> doesn’t do the trick.
> 0x7f6d94088a10 -- Strict RTP learning after remote address set to: 192.168.1.100:37785
-- Started music on hold, class 'default', on channel 'PJSIP/102-00000052'
> 0x7f6d94065b80 -- Strict RTP learning complete - Locking on source address 192.168.1.150:8492
-- Executing [*1103@default:1] NoOp("PJSIP/101-00000054", ""Exten: 103"") in new stack
-- Executing [*1103@default:2] BlindTransfer("PJSIP/101-00000054", "103") in new stack
-- Auto fallthrough, channel 'PJSIP/101-00000054' status is 'UNKNOWN'
a*CLI>
-- Executing [101@default:1] NoOp("PJSIP/102-0000005e", ""Llamada iniciada a 102"") in new stack
-- Executing [101@default:2] Festival("PJSIP/102-0000005e", "Llamando a alguien") in new stack
> 0x7f6d4003e700 -- Strict RTP learning after remote address set to: 192.168.1.133:33170
> 0x7f6d4003e700 -- Strict RTP switching to RTP target address 192.168.1.133:33170 as source
-- Executing [101@default:3] Dial("PJSIP/102-0000005e", "PJSIP/101/sip:101@192.168.1.201;transport=udp,Tt") in new stack
-- Called PJSIP/101/sip:101@192.168.1.201;transport=udp
[Mar 27 18:59:15] WARNING[6858][C-0000003f]: app_dial.c:2929 dial_exec_full: Invalid answer timeout specified: '(null)'. Setting timeout to infinite
-- PJSIP/101-0000005f is ringing
> 0x7f6d4003e700 -- Strict RTP learning complete - Locking on source address 192.168.1.133:33170
> 0x7f6d4004a130 -- Strict RTP learning after remote address set to: 192.168.1.201:35162
-- PJSIP/101-0000005f answered PJSIP/102-0000005e
-- Channel PJSIP/101-0000005f joined 'simple_bridge' basic-bridge <a9ab5107-c3f3-43ae-8dd3-3de06f7c10b9>
-- Channel PJSIP/102-0000005e joined 'simple_bridge' basic-bridge <a9ab5107-c3f3-43ae-8dd3-3de06f7c10b9>
> Bridge a9ab5107-c3f3-43ae-8dd3-3de06f7c10b9: switching from simple_bridge technology to native_rtp
> Remotely bridged 'PJSIP/102-0000005e' and 'PJSIP/101-0000005f' - media will flow directly between them
(0x7f6d4003dda0) RTP audio difference is 69656 set mark
> 0x7f6d4004a130 -- Strict RTP learning after remote address set to: 192.168.1.201:35162
> 0x7f6d4004a130 -- Strict RTP learning after remote address set to: 192.168.1.201:35162
-- Started music on hold, class 'default', on channel 'PJSIP/102-0000005e'
-- Executing [*1103@default:1] NoOp("PJSIP/101-00000060", ""Exten: 103"") in new stack
-- Executing [*1103@default:2] BlindTransfer("PJSIP/101-00000060", "103") in new stack
-- Auto fallthrough, channel 'PJSIP/101-00000060' status is 'UNKNOWN'
> 0x7f6d4004a130 -- Strict RTP learning after remote address set to: 192.168.1.201:35162
-- Stopped music on hold on PJSIP/102-0000005e
a*CLI>
Here’s the complete log of a call, where I call from 102 to 101, then try to redirect to 103 in 101. (At least what I intend to happen).
The blind transfer call isn’t coming in on the same channel as the outgoing call to 101; it’s coming in from the phone’s second line; there is no bridge on that!
(The outgoing leg is -0000005f, and the one running blind transfer is -00000060. Asterisk will not consider them to be related.)
Why can’t you use a feature code, or a SIP blind transfer.
(It seems strange that there are two people asking about blind transfer applications, one AMI, and one dialplan, but both sufficiently unusual that I had to look them up. Are you connected?)
If there’s more straightforward method/function/etc feel free to suggest it , I’ve been struggling a tad to navigate through the documentation (and heaps of now deprecated/outdated webpages) and make a mind map of how it all fits.
Not that I can tell , unless they are also from a certain university and have been tasked on a certain subject to configure asterisk to implement XYZ features.
To avoid an XY problem, the end goal is being able to have the callee redirect the caller of an ongoing call between two people using PJSIP to another extension, whatever method that goes through.