[asterisk-dev] [Code Review] Issues with DTMF triggered attended transfers.

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1047/#review3028
-----------------------------------------------------------


I'm concerned about the usage of the NULL channel technology here and its impact on dialplan processing after a transfer has occurred.  For example, consider post-call processing done in the 'h' extension of the dialplan.  If the channel is no longer a SIP channel (or whatever type it was originally), there are some things that will no longer work.  As an example, items retrieved using the CHANNEL() function that depend on the channel type will no longer work.

Unfortunately, I don't really have a suggestion for how to deal with this.  There is just some very fundamental breakage between the callback mechanisms here and channels tied to a physical resource that have not been released.  I'll keep thinking about it and let you know if I can think of something better.  We could potentially just put in a hack that disables the callback on DAHDI channels, but that doesn't feel too great, either.

- Russell


On 2010-12-03 19:00:55, rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1047/
> -----------------------------------------------------------
> 
> (Updated 2010-12-03 19:00:55)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> 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.
> 5) A hangup. C still ringing until "atxfernoanswertimeout" expires.
> 
> 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, C ringing (no answer)
> 3. B hangup
> 4. C cancel call
> 5. Call 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.
> 
> 
> This addresses bugs 17273, 17999 and 18395.
>     https://issues.asterisk.org/view.php?id=17273
>     https://issues.asterisk.org/view.php?id=17999
>     https://issues.asterisk.org/view.php?id=18395
> 
> 
> Diffs
> -----
> 
>   /branches/1.6.2/main/features.c 297577 
> 
> Diff: https://reviewboard.asterisk.org/r/1047/diff
> 
> 
> Testing
> -------
> 
> Party A - transferee
> Party B - transferer
> Party C - target of transfer
> 
> A and B are connected (It does not matter who called whom for these tests.)
> B requests attended transfer feature by dialing *2 feature.
> 
> B fails to dial party C (Check A & B audio)
> B dials wrong number (Check A & B audio)
> B cancels call to party C with '*' (Check A & B audio)
> C is the parking extension (Outside the scope of this patch)
> C does not answer before timeout (Check A & B audio)
> C is busy (Check A & B audio)
> A hangs up before C answers (Check if A is completely released)
> 	(If A is an analog port it is dead until the user
> 	 configured xferfailsound completes playing.)
> 	(Test case is issue 17273 and issue 18395 related)
> C answers before B hangup (Attended transfer)
> 	A still online
> 		C hangs up first (Check A & B audio)
> 		B hangs up first (Check A & C audio)
> 	A hangs up (Check if A is completely released)
> 		(If A is an analog port it is dead until B or C hangs up)
> 		(Test case is issue 17273 and issue 18395 related)
> 		C hangs up first (Check B audio)
> 		B hangs up first (Check C audio)
> B hangs up before C answers (Blonde transfer) (Check if B is completely released)
> 	(Test case is issue 17273 and issue 18395)
> 	A hangs up (C should quit ringing immediately)
> 		(Test case is issue 17999)
> 	C answers (Check A & C audio)
> 	C does not answer before timeout
> 		A hangs up when B redialed (B should quit ringing immediately)
> 			(Test case is issue 17999 related)
> 		B answers recall (Check A & B audio)
> 		A hangs up when sleeping before redialing C (A should be released immediately)
> 			(Test case is issue 17999 related)
> 		A hangs up when C redialed (C should quit ringing immediately)
> 			(Test case is issue 17999 related)
> 		C answers recall (Check A & C audio)
> 		Noone answers (Check A audio)
> 
> Tests passed with exceptions noted.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20101213/9d6b9ff8/attachment.htm