Summary:ASTERISK-08512: Attended Transfer with Polycom handset results in stuck call.
Reporter:Tass Iliopoulos (tass)Labels:
Date Opened:2007-01-08 00:11:29.000-0600Date Closed:2007-03-26 12:42:44
Versions:Frequency of
Environment:Attachments:( 0) sip_debug.txt
( 1) SIP_debug_output_for_transfer.txt
Description:An attended transfer from SIP/A to SIP/B leaves SIP/B's line on hold instead of in conversation with the transferred party.
The call state is also incorrect because the hold can't be resumed unless hold is pressed again (eg call is held, I need to press HOLD then RESUME to get the call back).


PSTN places call to SIP/A
SIP/A begins attended transfer to SIP/B
SIP/A completes attended transfer by pressing transfer button
SIP/B now has PSTN on hold

Pressing the line key will not resume the call, instead the call needs to be held again then resumed.


I've included a sip debug summary of SIP/tassi2 (equivalent to SIP/A). Unfortunately, it seems you can no longer debug 2 sip peers at a time.

I hope I have included enough information - I will be rolling back to 1.2 shortly.
Comments:By: Serge Vecher (serge-v) 2007-01-08 13:47:05.000-0600

I think this may be related to a fix hold counter, which was fixed in 1.4 branch r49831. Can you please give that a try?

By: Tass Iliopoulos (tass) 2007-01-08 15:37:00.000-0600

Thanks for the update.
I'll have to upgrade our old server which will take me a while, but will update with how it went.

By: Joshua C. Colp (jcolp) 2007-01-10 23:57:47.000-0600

Please give 1.4 as of revision 50468 a try. Thanks!

By: Tass Iliopoulos (tass) 2007-01-22 00:59:02.000-0600

I've tested on Asterisk SVN-branch-1.4-r51274, and there is now a new problem. The good news, though, is that the original problem is solved.

When SIP/A tries to speak to SIP/B before completing the transfer, there is no audio going between the phones (although an RTP debug shows plenty of packets) so SIP/A and SIP/B cannot hear eachother.

SIP/A, though, can complete the transfer and PSTN and SIP/B can now hear eachother. I've attached debug output.

A regular call between SIP/A and SIP/B works perfectly - there is only a problem when doing an attended transfer.

By: Serge Vecher (serge-v) 2007-01-29 09:04:43.000-0600

Ok, we need to see some debug information, please redo sip debug as per following:
1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterisk with the following command:
  'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Trim startup information and attach verbosedebug.txt to the issue.

By: Joshua C. Colp (jcolp) 2007-02-15 10:50:19.000-0600

Can you clarify on what the IP address "" is allocated to? I noticed it in the SDP for where audio should be sent, and it just appeared out of nowhere... quite odd.

By: Tass Iliopoulos (tass) 2007-02-15 16:02:32.000-0600 is another phone - Polycom 430 - but it's actually registered to a different server. So, yes it's strange.

I'll try get some time to test with full debug in the next few days.

By: pinga-fogo (pinga-fogo) 2007-02-17 18:00:33.000-0600

i have a simmilar problem, and its no only for ptsn calls, this occurs on all transfers wen asterisk in the signal path,,, ex


PolyA calls PolyB,,, PolyB attended transfer to PolyC, all works fine,,,

a IAXPhone Calls PolyA,, works fine,, PolyA attended transfer to PolyB, iax is on hold ,,, polyA talks with polyB,, when the polyA press the transfer button, IAXphone cant hear polyb and polyb cant hear iaxphone,,

its the same on the ptsn, h323 or all another transfers when asterisk in the path...

if i use canreinvite=no ,,, all works fine,,, but if i use canreinvite=yes i have this problem!!

By: Serge Vecher (serge-v) 2007-03-05 14:33:13.000-0600

tass, what's the status here with 1.4.1, debug log?

By: Serge Vecher (serge-v) 2007-03-26 12:42:43

no response for over a month. If still an issue in 1.4.2, please reopen with logs requested.