[asterisk-bugs] [Asterisk 0014356]: SIP attended transfer cannot re-transfer a caller after a call forward no answer rule returns call to original extension

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14356 
====================================================================== 
Reported By:                aragon
Assigned To:                otherwiseguy
====================================================================== 
Project:                    Asterisk
Issue ID:                   14356
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.23 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!): 170394 
Request Review:              
====================================================================== 
Date Submitted:             2009-01-28 10:04 CST
Last Modified:              2009-01-29 18:47 CST
====================================================================== 
Summary:                    SIP attended transfer cannot re-transfer a caller
after a call forward no answer rule returns call to original extension
Description: 
Here is setup:
6011 will call 6002
6002 will transfer to 6010
6010 has forward no answer rule to 6002
6002 must answer and try to transfer caller to another extension using SIP
attended transfer (Polycom phone firmware 3.1.1

Result:
after timeout to 6010 caller is sent to vm6002 instead of transferred back
to 6002 (core show channels does not show 6002 on call after transfer
completion.

Note:
The only workaround for this is to use SIP blind transfer.
Native *1 Asterisk transfer will follow the call forward no answer rule on
6010 to transfer to 6002, but once the caller is returned to 6002 then 6002
cannot use the blind transfer feature again
====================================================================== 

---------------------------------------------------------------------- 
 (0099107) aragon (reporter) - 2009-01-29 18:47
 http://bugs.digium.com/view.php?id=14356#c99107 
---------------------------------------------------------------------- 
otherwiseguy

There are definitely some minor issues with the patch which I have no
issues reproducing.
Both issues are related to *1 or *2 transfers
And use "silly" call forward no answer rule ;)

I set up a call forward no answer rule on 220 to return transfers from 233
back to 220 after a few seconds

User makes steps to reproduce

222 calls 233
233 *1220
call forward no answer to 233
233 answers then *2220 and caller is sent to voicemail
It appears that the from extension after 233 answers and *2220 is
rewritten to 220 and not 233 and loops to voicemail

-- <SIP/233-09472ff8> Playing 'pbx-transfer' (language 'en')
    -- Executing [220 at commzilla-super:1]
GotoIf("Local/220 at commzilla-super-b94a,2", "0?3") in new stack
  -- Executing [s at macro-commzilla-dial:1]
NoOp("Local/220 at commzilla-super-b94a,2", ""CALL TO LOCAL EXTENSION FROM
220()"") in new stack
   
This problem only exists when you transfer a call twice and use *1 during
the first transfer attempt and *2 for the second transfer attempt.
The test seems anal and horribly improbable in any real world scenario but
I can reproduce.
As I said this is a minor problem and I don't give it much thought...
If *1 is used repetitively to re-transfer caller then everything works
fine.


Things are a little more dicey with *2 because *2 cannot be re-used for
multiple transfers on the original caller.

User makes steps to reproduce

222 calls 233
233 *2220
call forward no answer to 233
233 answers then *2220 but gets no response from Asterisk
Therefore *2 cannot be reused after the call forward no answer returns the
caller ext 222, from 220, back to 233

I know the call forward no answer rule sounds silly but the customer
demands that it work.

I don't have any problems with SIP transfers with patch from 14274; only
the issues stated above. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-29 18:47 aragon         Note Added: 0099107                          
======================================================================