[test-results] [Bamboo] Asterisk - 1.6.2 > Ubuntu Lucid (10.04) > #125 was SUCCESSFUL (with 92 tests). Change made by rmudgett.

[Bamboo]

-----------------------------------------------------------------------
Asterisk - 1.6.2 > Ubuntu Lucid (10.04) > #125 was successful.
-----------------------------------------------------------------------
Code has been updated by rmudgett.
All 2 jobs passed with 92 tests in total.

http://bamboo.asterisk.org/browse/AST162-LUCID-125/


--------------
Code Changes
--------------
rmudgett (302173):

>Merged revisions 302172 via svnmerge from 
>https://origsvn.digium.com/svn/asterisk/branches/1.4
>
>........
>  r302172 | rmudgett | 2011-01-18 12:04:36 -0600 (Tue, 18 Jan 2011) | 88 lines
>  
>  Issues with DTMF triggered attended transfers.
>  
>  Issue #17999
>  1) A calls B. B answers.
>  2) B using DTMF dial *2 (code in features.conf for attended transfer).
>  3) A hears MOH. B dial number C
>  4) C ringing. A hears MOH.
>  5) B hangup. A still hears MOH. C ringing.
>  6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
>  For v1.4 C will ring forever until C answers the dead line. (Issue #17096)
>  
>  Problem: When A and B hangup, C is still ringing.
>  
>  Issue #18395
>  SIP call limit of B is 1
>  1. A call B, B answered
>  2. B *2(atxfer) call C
>  3. B hangup, C ringing
>  4. Timeout waiting for C to answer
>  5. Recall to B fails because B has reached its call limit.
>  
>  Because B reached its call limit, it cannot do anything until the transfer
>  it started completes.
>  
>  Issue #17273
>  Same scenario as issue 18395 but party B is an FXS port.  Party B cannot
>  do anything until the transfer it started completes.  If B goes back off
>  hook before C answers, B hears ringback instead of the expected dialtone.
>  
>  **********
>  Note for the issue #17273 and #18395 fix:
>  
>  DTMF attended transfer works within the channel bridge.  Unfortunately,
>  when either party A or B in the channel bridge hangs up, that channel is
>  not completely hung up until the transfer completes.  This is a real
>  problem depending upon the channel technology involved.
>  
>  For chan_dahdi, the channel is crippled until the hangup is complete.
>  Either the channel is not useable (analog) or the protocol disconnect
>  messages are held up (PRI/BRI/SS7) and the media is not released.
>  
>  For chan_sip, a call limit of one is going to block that endpoint from any
>  further calls until the hangup is complete.
>  
>  For party A this is a minor problem.  The party A channel will only be in
>  this condition while party B is dialing and when party B and C are
>  conferring.  The conversation between party B and C is expected to be a
>  short one.  Party B is either asking a question of party C or announcing
>  party A.  Also party A does not have much incentive to hangup at this
>  point.
>  
>  For party B this can be a major problem during a blonde transfer.  (A
>  blonde transfer is our term for an attended transfer that is converted
>  into a blind transfer.  :)) Party B could be the operator.  When party B
>  hangs up, he assumes that he is out of the original call entirely.  The
>  party B channel will be in this condition while party C is ringing, while
>  attempting to recall party B, and while waiting between call attempts.
>  
>  WARNING:
>  The ATXFER_NULL_TECH conditional is a hack to fix the problem.  It will
>  replace the party B channel technology with a NULL channel driver to
>  complete hanging up the party B channel technology.  The consequences of
>  this code is that the 'h' extension will not be able to access any channel
>  technology specific information like SIP statistics for the call.
>  
>  ATXFER_NULL_TECH is not defined by default.
>  **********
>  
>  (closes issue #17999)
>  Reported by: iskatel
>  Tested by: rmudgett
>  JIRA SWP-2246
>  
>  (closes issue #17096)
>  Reported by: gelo
>  Tested by: rmudgett
>  JIRA SWP-1192
>  
>  (closes issue #18395)
>  Reported by: shihchuan
>  Tested by: rmudgett
>  
>  (closes issue #17273)
>  Reported by: grecco
>  Tested by: rmudgett
>  
>  Review: https://reviewboard.asterisk.org/r/1047/
>........
>


--------------
Tests
--------------
Fixed Tests (1)
   - AsteriskTestSuite: S/feature blonde transfer

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20110118/00e9fcdc/attachment.htm>