[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 noreply at bugs.digium.com
Thu Jan 29 10:59:50 CST 2009


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:                     acknowledged
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 10:59 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
====================================================================== 

---------------------------------------------------------------------- 
 (0099068) otherwiseguy (administrator) - 2009-01-29 10:59
 http://bugs.digium.com/view.php?id=14356#c99068 
---------------------------------------------------------------------- 
What this amounts to is the polycom calling itself, which anytime I have
ever tried to do results in the polycom hanging up on itself.

For the case where it goes to voicemail when it shouldn't, that is almost
certainly the Dial() timeout being less than the amount of time that the
polycom is set for detecting a no answer.  The ngrep output confirms this
becuase there is no 302 from the Polycom, there is a CANCEL sent by
Asterisk,which is what should happen.  Either make the Dial timeout longer,
or scroll down and set the number of rings for a call forward no answer
something less than what it is (the default I think is 10 rings).

For the case where the call is in fact 302 redirected back to the caller,
the phone will have 1 call up to the original caller, one call up for the
consultative transfer, then will be receiving yet another call from
asterisk for the redirect.  Often times the max calls per line is set to
two, so the incoming call would fail.

Neither of the above cases is a bug.

The built-in blind transfer issue you refer to is a bug, but should be
fixed by the patch in 14274. After I have a couple of other people look at
it and test it out, I'll get that committed to the 1.4 branch and merged to
the other branches. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-01-29 10:59 otherwiseguy   Note Added: 0099068                          
======================================================================




More information about the asterisk-bugs mailing list