I’ve got a strange issue with transferring a call on my system.
101 makes a call to 102
102 transfers 101 to 103 (attended transfer)
101 can now never transfer the call, even though it’s allowed in the dialplan (tT)…
in another scenario: -
101 makes a call to 102
101 transfers 102 to 103
102 can now never transfer the call…
It seems as though the 1st extension to do a transfer, passes on the right to transfer to the ext it’s transfering to.
the problem extension can DTMF to do the transfer (*7), gets the prompt to “transfer”, is allowed to dial the extension AND talk to it to announce the call through, but when hanging up to pass the call through, all the calls hangup…
Only exotic thing I’m doing is using the asterisk TRANSFER_CONTEXT variable to use a custom transfer context that dials the extension as a “LOCAL” dial.
What version? What technology? Within that technology, exactly which transfer mechanism? E.g. a sip transfer could be a features.conf transfer, a true blind transfer, an attended transfer, or an attended transfer simulating a bind transfer.
There is code in Asterisk that prevents a call being multiply routed to the same device when you use & on dial. I think this can be confused on transfers, although I had a feeling it was fixed about six months ago.
iv’e got asterisk 1.8.20.1 newly installed
Using SIP all the way (I’m just testing with 3 SIP extensions)
I’m using “*7” to transfer
*I’ve got “allowtransfer=no” in my sip.conf to block extension transfers and just use Asterisk
my features.conf just uses: -
[featuremap]
blindxfer => *8
atxfer => *7
I’m however just using attended transfers to check, as I consider blind ones to be bad transfers.
I also tried doing a semi-attended transfer, in which an extension started with an attended transfer, but hung up to fully transfer the call before the called extension answered.
However I got the same result, all the calls got hung-up.
What I’ll do now is add in another extension (104), and see if I can replicate with transferring there on the last call.
Tested adding in an extension (104), and call still hung-up up completely, what I did was: -
101 makes a call to 102
102 transfers 101 to 103 (attended transfer)
103 transfers 101 to 102 (attended transfer)
101 transfers 102 to 104 - Entire call gets hang-up when completing the transfer
interestingly though, I can see a possible problem, when typing in “core show channels” in the cli, I get this: -
1101 calls 1102
1101 attended transfers 1102 to 1103
Channel Location State Application(Data)
Local/1103@transferr 1103@transferrr_cont Up Transferred Call(SIP/1102-0000
Local/1103@transferr 1103@attended-trans- Up Dial(Local/tra1103@fourdigit/n
SIP/1102-00000050 s@app_dial_gosub_vir Up Transferred Call(Local/1103@tr
Local/tra1103@fourdi 1103@fourdigit:24 Up Dial(SIP/1103,25,TtU(four-pick
Local/tra1103@fourdi s@app_dial_gosub_vir Up AppDial((Outgoing Line))
SIP/1103-00000051 s@app_dial_gosub_vir Up AppDial((Outgoing Line))
at this point 1102 is now talking to 1103.
Then when this happens: -
1103 attended transfers (back) to 1101
Channel Location State Application(Data)
Local/1103@transferr 1103@transferrr_cont Ringing Transferred Call(SIP/1102-0000
Local/1103@transferr 1103@attended-trans- Up Dial(Local/tra1103@fourdigit/n
SIP/1101-00000052 s@app_dial_gosub_vir Up AppDial((Outgoing Line))
Local/1101@transferr 1101@transferrr_cont Up Transferred Call(Local/tra1103
Local/1101@transferr 1101@attended-trans- Up Dial(Local/tra1101@fourdigit/n
Local/tra1101@fourdi s@app_dial_gosub_vir Up AppDial((Outgoing Line))
Local/tra1101@fourdi 1101@fourdigit:24 Up Dial(SIP/1101,25,TtU(four-pick
SIP/1102-00000050 s@app_dial_gosub_vir Up Transferred Call(Local/1103@tr
Local/tra1103@fourdi 1103@fourdigit:24 Up Transferred Call(Local/1101@tr
Local/tra1103@fourdi s@app_dial_gosub_vir Ringing AppDial((Outgoing Line))
i have some ringing states in there, even though I’ve transferred the call…
I don’t get it, my “transferrr_contexty” (awesome name for a context) simply does a “Goto” to another context which does the actual dial, so why does asterisk say that the transferrr_contexty is in a “ringing” state?