[Home]

Summary:ASTERISK-09367: No ringing heard on unattanded transfer
Reporter:Richard Wilkinson (rickead2000)Labels:
Date Opened:2007-05-02 07:13:03Date Closed:2007-12-05 15:26:48.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:When performing an unattended transfer, the caller hears silence whilst the transferee's phone is ringing.  I believe the caller should hear ringing.

This issue is present in 1.4.4

****** ADDITIONAL INFORMATION ******

In this example, a call comes in and is answered by 101.  101 attempts to unattended transfer to 150.  Whilst the transfer succeeds, the caller hears only silence during the transfer (apart from music on hold for the short period whilst the transfer is being set up)

Output from logs....


[May  2 13:08:42] VERBOSE[27292] logger.c:     -- Called 101
[May  2 13:08:42] VERBOSE[27292] logger.c:     -- SIP/101-09f76c00 is ringing
[May  2 13:08:44] VERBOSE[27292] logger.c:     -- Call on SIP/101-09f76c00 left from hold
[May  2 13:08:44] VERBOSE[27292] logger.c:     -- SIP/101-09f76c00 answered SIP/87.157.62.201-09f7d518
[May  2 13:08:46] VERBOSE[27292] logger.c:     -- Started music on hold, class 'default', on SIP/87.157.62.201-09f7d518
[May  2 13:08:48] VERBOSE[27299] logger.c:     -- Executing [150@main:1] Answer("SIP/101-09f872c8", "") in new stack
[May  2 13:08:48] VERBOSE[27299] logger.c:     -- Executing [150@main:2] Dial("SIP/101-09f872c8", "SIP/test1") in new stack
[May  2 13:08:48] VERBOSE[27299] logger.c:     -- Called test1
[May  2 13:08:48] VERBOSE[27299] logger.c:     -- SIP/test1-09f8c1b0 is ringing
[May  2 13:08:48] VERBOSE[27129] logger.c:     -- Stopped music on hold on SIP/87.157.62.201-09f7d518
[May  2 13:08:48] DEBUG[27129] chan_sip.c: SIP transfer: Succeeded to masquerade channels.
[May  2 13:08:52] VERBOSE[27292] logger.c:   == Spawn extension (ext, 101, 3) exited non-zero on 'SIP/101-09f872c8<ZOMBIE>'
[May  2 13:08:53] VERBOSE[27299] logger.c:   == Spawn extension (main, 150, 2) exited non-zero on 'SIP/87.157.62.201-09f7d518'
Comments:By: Joshua C. Colp (jcolp) 2007-05-03 11:15:50

This looks like an attended transfer, not unattended in which case there is an issue that I have found that would cause this. I will look for a potential patch this evening I have and attach it so you can try it.
By: Richard Wilkinson (rickead2000) 2007-05-03 16:43:57

Hi.  You are correct - it is actually an attended transfer - (i tend to use attended as unattended, i.e. hangup the receiver before the transferee picks up) my mistake

Just to clarify, if the transfer is announced correctly there is no issue.  It's only when the transfer is sent through before the transferee answers that the caller hears no audio.

As most VoIP phones offer their own transfer feature, which is normally only attended transfer, this is the only way to easily perform an unattended transfer.
By: Igor Goncharovsky (igorg) 2007-05-03 22:44:01

rickead2000, can you try latest trunk with this feature? Recently committed patch with updated atxfer (0008413). As I known hangup receiver before the transferee picks up cause hangup caller and transferee channels.


By: Ronald Chan (loloski) 2007-05-04 11:01:31

IgorG: i think this issue has been fixed, hanging off (transferer) while doing attended transfer both the caller and the intended callee was hangup
By: Ronald Chan (loloski) 2007-05-04 11:04:46

r62547 | russell | 2007-05-02 05:55:19 +0800 (Wed, 02 May 2007) | 4 lines

Remove an unnecessary check that makes it so if you hang up after doing an
attended transfer before the target extension answers the channel, the transfer
is not successful.  (issue ASTERISK-9066, patch by svanlund)

Sorry i know this is not the right place to discuss unrelated bug. my bad..
By: Richard Wilkinson (rickead2000) 2007-05-05 05:38:21

I'll compile the latest trunk later on today and post back results.

Thanks!
By: Richard Wilkinson (rickead2000) 2007-05-09 03:20:28

Issue still seems to be present in the latest trunk
By: Joshua C. Colp (jcolp) 2007-05-24 10:01:59

Please try the http://svn.digium.com/svn/asterisk/team/file/issue_9650 branch. It's based on trunk but the changes were so minor I may backport it if it fixes it.
By: Richard Wilkinson (rickead2000) 2007-05-24 10:33:09

Behaviour does'nt seem to have changed.

Output from asterisk...

   -- Executing [123@default:1] Answer("SIP/09f6c3e0", "") in new stack
   -- Executing [123@default:2] Dial("SIP/09f6c3e0", "SIP/101|60|Tt") in new stack
 == Using TOS bits 0
 == Using CoS mark 0
   -- Called 101
   -- SIP/101-09f6db18 is ringing
   -- SIP/101-09f6db18 answered SIP/09f6c3e0
   -- Started music on hold, class 'default', on SIP/09f6c3e0
   -- <SIP/101-09f6db18> Playing 'pbx-transfer.slin' (language 'en')
   -- Executing [102@internal:1] Answer("Local/102@internal-fb0c,2", "") in new stack
[May 24 17:29:18] WARNING[14528]: cdr.c:771 ast_cdr_init: CDR already initialized on 'Local/102@internal-fb0c,1'
   -- Executing [102@internal:2] AGI("Local/102@internal-fb0c,2", "internalcall.php|102") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/internalcall.php
   -- AGI Script Executing Application: (Dial) Options: (SIP/102|180|T))
 == Using TOS bits 0
 == Using CoS mark 0
   -- Called 102
   -- SIP/102-09f671b0 is ringing
   -- Stopped music on hold on SIP/87.117.64.172-09f6c3e0
   -- <Local/102@internal-fb0c,1> Playing 'beep.slin' (language 'en')
 == Spawn extension (default, 123, 2) exited non-zero on 'Transfered/SIP/87.117.64.172-09f6c3e0<ZOMBIE>'
   -- SIP/102-09f671b0 answered Local/102@internal-fb0c,2
   -- AGI Script internalcall.php completed, returning 0
By: Richard Wilkinson (rickead2000) 2007-05-28 05:10:43

I should say that the devel box that is running on uses an agi app to dial internal extensions.  I have tried it using just the dialplan aswell to rule out any issue with trasfer on the AGI Dial but issue is still present.

It would seem that asterisk is actually performing the transfer too soon.  We can see that it plays the beep audio as soon as the transferer puts the receiver down.  I would guess it also attempts to bridge audio at the time aswell, instead of playing ringing
By: Richard Wilkinson (rickead2000) 2007-10-04 03:03:49

This bug still seems to be present in 1.4.11.  Did anyone manage to resolve it?  Many thanks.
By: Mark Michelson (mmichelson) 2007-10-04 22:38:29

Hmmm, I'm curious about something. I haven't seen your dialplan yet, but it looks like you're doing an attended transfer to a local channel, and it looks like that local channel has an Answer() in it before it calls the AGI script. What happens if you remove the Answer()?
By: Richard Wilkinson (rickead2000) 2007-10-05 05:02:48

Hi Putnopvut - I have removed the answer and the behavior seems to be the same.

dial plan of transferee...

exten => 101,1,Dial(SIP/101,30)

still has this behaviour.  Any ideas?
By: crea (crea) 2007-11-08 17:05:51.000-0600

I'm using 1.4.11 and I have this problem too.
If I do an anttended transfer and I hangup before the destination is reached, the tranfered caller hears silence. Until the destination answer the call.


By: Richard Wilkinson (rickead2000) 2007-11-09 03:20:15.000-0600

It's still present in 1.4.13.

Does anybody know when this can be looked into?  It's very confusing to caller and critically hampers asterisk's transfer functionality.

Thanks
By: Ted Brown (ted brown) 2007-11-09 07:39:27.000-0600

I have been able to reproduce this problem, not only with asterisk's attended transfer but also by bridging two lines in a phone.
I guess the problem is that asterisk stops moh unconditionally when the opposite channel hangs. Isn't it possible to check if our channel is been bridged prior to stopping it?
By: Nic Bellamy (nic_bellamy) 2007-11-19 19:30:50.000-0600

I can reliably reproduce this (disclaimer: this was on 1.2.24; I don't have a 1.4.x box around right now - but I suspect it's the same root cause).

Pre-requisites: SIP phone that will allow you to complete an attended transfer while the destination is still ringing (I'm using Polycom phones).

1. A calls B
2. B answers
3. B starts attended transfer to C, and A starts hearing MOH
4. B hears ringing, completes transfer - A stops hearing MOH, getting dead silence instead, until...
5. C eventually answers phone or call goes to voicemail, at which point A gets audio again

This happens whether A is a SIP phone or a call coming from a PRI.

What seems to be happening is that answered channel A ends up being connected to unanswered channel C - but the ringing indication from C has already been consumed by B, so A never gets it.

What I suspect needs to be happen is that when the channel is masqueraded, an indication of C's current state needs to be queued to A's channel (ie. ast_queue_control(..., AST_CONTROL_RINGING) or whatever is appropriate at the time)

Plausible?
By: Andrew Lindh (andrew) 2007-11-26 15:43:28.000-0600

I have the same attended transfer problem too...blind (unattended) transfers work as expected (other party hears rining)....using 1.4 branch.


By: Joshua C. Colp (jcolp) 2007-12-05 10:24:19.000-0600

This has been fixed in 1.4 and trunk.
By: Joshua C. Colp (jcolp) 2007-12-05 15:26:48.000-0600

Fixed in 1.4 as of revision 90548 and trunk as of revision 90550.