[asterisk-users] Blind transfers being cancelled by asterisk & hanging up on remote caller

Luke Hamburg luke at solvent-llc.com
Sun Jan 8 15:02:15 CST 2012


Are we the only 2 people on this list experiencing this issue?  (surprised)

Anyone else have any insights?

My hunch is that this is likely some type of FreePBX issue with how it generates the [from-internal-xfer] context.

 

 

From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Douglas Mortensen
Sent: Saturday, January 07, 2012 3:16 PM
To: asterisk-users at lists.digium.com
Subject: Re: [asterisk-users] Blind transfers being cancelled by asterisk & hanging up on remote caller

 

Oh crap. I just reread the previous post & realized I'm not alone. Hallelujah! I'll post back more info soon.

-
Doug Mortensen 
Sent via DroidX2 on Verizon Wireless™



-----Original message-----

From: Ryan Wagoner <rswagoner at gmail.com>
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users at lists.digium.com>
Sent: Sat, Jan 7, 2012 15:59:36 GMT+00:00
Subject: Re: [asterisk-users] Blind transfers being cancelled by asterisk & hanging up on remote caller

 

On Sat, Jan 7, 2012 at 5:19 AM, Luke Hamburg <luke at solvent-llc.com> wrote:

Doug:
for what it's worth I am having the exact same nightmare.  Not sure exactly
when it started but I believe it was a change in 1.8.8.1 / 1.8.9.0-rc1 (I am
running 1.8.9rc1).  I also have Polycom (335, 550, 650)  and blind transfers
are broken.  All legs of the call are dropped when the xfer is executed.  A
calls B, B xfer to C and (C) blips for a split second like its ringing but
then all calls go dead.  I tried to debug myself using some sip tracing but
I didn't get very far.  I even tried mucking around with a few settings in
my Polycom provisioning I thought might be related e.g.

 voIpProt.SIP.allowTransferOnProceeding
 voIpProt.SIP.connectionReuse.useAlias
 voIpProt.SIP.useContactInReferTo
 voIpProt.SIP.conference.parallelRefer
 voIpProt.SIP.strictLineSeize
 voIpProt.SIP.strictUserValidation
 voIpProt.SIP.strictReplacesHeader
 voIpProt.SIP.useContactInReferTo

and also upgraded to the new 3.3.4 firmware which is out yesterday,  didn't
change a thing.
stuck here for now,  Attended xfers seem to work.    I am not sure this is a
Polycom-specific issue because I was seeing this bad behavior even using
some Softphones I set up for testing.

my next recourse is to try rolling back to 1.8.8.0 or earlier and if that
fixes it then I will open a JIRA ticket with more details.

Luke


--
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Douglas
Mortensen
Sent: Thursday, January 05, 2012 3:04 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: [asterisk-users] Blind transfers being cancelled by asterisk &
hanging up on remote caller


Hello all,

I have a system running AsteriskNOW with asterisk asterisk-1.8.8.1-1_centos5
from AsteriskNOW repository. I just changed our Polycom 335 sip.conf so that
blindpreferred=1 (all transfers default as blind transfers). If a customer
calls in & we answer & transfer, everything works fine. But if we call out
to a customer & then transfer to another internal extension, that extension
quickly rings & then the call is immediately gone & hung up. We are using
Polycom firmware 3.3.3.

In troubleshooting this & analyzing the asterisk logs (& asterisk SIP
debug), I am seeing a few interesting items. Any help would be appreciated.

[...]

Thanks,
-
Doug Mortensen


I can't reproduce this on a test system with Asterisk 1.8.8.1 using a Polycom 335 and 550 running firmware 3.2.6. I called an external number using Vitelity then blind transferred to the other phone. I am interested as I have a production system with Polycom 335 phones running 1.8.7.0 that works.

Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20120108/1c904d27/attachment.htm>


More information about the asterisk-users mailing list